Transparent shims may not be so easy due to how the built-ins work and IDs get defined and resolved.
For timing, I would encourage using time() and delta from beforeRender rather than frame by frame based animations whenever possible. Features will be added that will change FPS dynamically such as cross fading between patterns (might slow down FPS), multi-segmenting, or even parallelization of rendering on additional cores.
As a work-around for frame by frame animations, patterns could detect their FPS by looking at delta values and adjust accordingly. When a fluid adjustment isn’t feasible, you could have 2 set points optimized for V2 and V3. One API I was thinking about that might help, or make some animations easier would be a skipRender() API that could be called in beforeRender() that would simply skip over the render calls and wouldn’t update the LEDs. This could be used to limit animation framerate, or in some cases optimize animation timing around some event or timer instead of re-rendering the same pixels which usually means buffering state right now.
I could see device ID being useful for having a single source with small variations, e.g. cloning a pattern out to ease distribution but allowing some customized code on each. Practically using this in a pattern by pasting in some random number like 12345.6789 feels awkward, maybe if it used the name like isNamed("Node 1") or something?