System Information
Operating system: macOS-11.5.2-x86_64-i386-64bit 64 Bits
Graphics card: AMD Radeon Pro 5600M OpenGL Engine ATI Technologies Inc. 4.1 ATI-4.6.20
Also tested on:
Operating system: macOS-10.14.6-x86_64-i386-64bit 64 Bits
Graphics card: AMD Radeon R9 M395X OpenGL Engine ATI Technologies Inc. 4.1 ATI-2.11.26

Blender Version
Broken: version: 2.93.5 Release Candidate, branch: master, commit date: 2021-09-01 11:53, hash: rBae1a57a05eed
Broken: version: 2.93.4, branch: master, commit date: 2021-08-31 09:23, hash: rBb7205031cec4
Broken: version: 2.93.3, branch: master, commit date: 2021-08-17 18:30, hash: rB8b80d19f3641
Worked: Unknown

Short description of error
Modifier Properties panel inputs are not updating within Geometry Nodes reliably during animations, and as scene complexity increases, the amount and severity of the errors increase.

Exact steps for others to reproduce the error

• Create Geometry Node system
• Create inputs for use in the Modifier Properties panel
• Create keyframed or driver based animations in the Modifier Properties panel
• Duplicate the object many times (see notes below)
• Play through the animation: some objects may not update every frame
• Render the animation: if the playhead is not at frame 0, the first frame rendered may randomly use different keyframe values, and if frames are rendered non-linearly (very common in some workflows if you render every 10th or 5th frame initially, then render the rest of the frames later) the input values may be randomly corrupted
  • This is how I created the example animation: I rendered frame steps of 10, 5, 2, and then 1. While the animations are entirely deterministic (a combination of keyframes and frame/300 drivers, none of which would ever change from render to render), the resulting animation is jittery and randomly uses values from incorrect frames (something wrong with the frame update system?).

Notes

• This issue appears to be dependent on the complexity of the scene. Just 3-4 objects may not produce consistently noticeable issues, but depending on scene complexity, 5-10 Geometry Node objects can be enough to push it over the edge (which is how I discovered it during a client production)
  • If the scene complexity is enough to drop playback below 15fps, the errors start to become easily visible in the viewport, typically showing up as asynchronous geometry updates; some objects will update on one frame, others on the next, and the entire playback is jittery and buggy
  • While not replicated in the example scene (it's still not complex enough), I've seen it get so bad that stepping through an animation doesn't even update geometry positions half the time
• Using the same Geometry Nodes group on multiple objects is NOT required, it's just easier to demonstrate this way. Using unique Geometry Node groups will produce similarly buggy results
• The attached demo project uses a LOT of objects, and replication of the issue seems to be reliable in my tests (still not as severe as my client project, but that is of course under NDA and cannot be shared)

Partial workarounds (not fully vetted, but included in case they help point to the root culprit)

• Using keyframes or drivers within the Geometry Node system works as expected (but cannot be customised per-object; these are by nature global to all objects using the node group, so not an option for systems that need variations per instance)
• Using drivers within the Geometry Node system that are referencing the input fields in the Modifier Properties panel also works, you just can't connect those inputs directly within the nodes (but again, global to all objects using that node group since that driver reference isn't dynamic per-object, so not an option for animations that need variations per object)
• Using an object input in the Modifier Properties, then getting the position, rotation, and scale values as values within the Geometry Nodes group does seem to work, and based on some limited testing, appears to work ok across multiple uses of the same group on different objects with different object references (this is the only potential workaround I've found so far that allows for different inputs per-object using the same Geometry Nodes group)