During Cntl F12 rendering, the lifetime of members of a mesh object's
particlesystem list is one frame. The dependency graph is updated,
once per frame, to accommodate myriad frame-to-frame changes in
animation curves and other volatiles.

From a mesh object's prospect, such an update entails calling
BKE_object_free(Object *ob), object.c:553 at the conclusion of a frame
render, which, per comments near the function, releases any data used
by the object, but not the object itself. The idea, I gather, is that
such data reflects a great deal of the just-rendered frame state, and
it is quite straightforward to establish new state by first flushing
the old data buffers, then reconstructing them anew to accommodate all
of the aforementioned volatiles. Thus, all of the particle system
elements in ob->particlesystem are released. The presumption is, I
think, that in the course updating the dependency graph state, the
state of particle systems can be updated (completely) as well. Perhaps
this presumption stems from an incomplete appreciation of how
extensive these data structures are, and that any attempt at
reconstructing their state is tatamount to actually re-running the
simulation from frame 1 at the start of every frame.

In particular, at MOD_particlesystem.c:131 (in deformVerts()), is called
during dependency graph update, before a frame is rendered. The mesh
object is found to have reconstructed particle systems in
ob->particlesystem (psys objects), but these objects lack valid
psys->particles pointers. Normally, psys->particles has M entries for
the M hairs in the system, and each entry maintains a cache
of S + 1 items. These items track frame-to-frame positions, velocities
and rotations of of the S + 1 'hair vertices'[1] and establish the
positions of the S segments that constitute the hair rooted to the
base particle.

A cloth simulation expects this M X S + 1 'array'[2] to persist from
frame-to-frame, but it is exactly this database that is flushed in
BKE_object_free() - and not restored - as evidenced by the elided
psys->particle pointers. Continuing with the array analogy for a bit,
it is as if M 'row headers' describing the M root particle positions
are reconstructed, but the S + 1 items in that row, the snapshot of
hair vertices dynamics at a particular frame of time, are lost. These
cannot be reconstructed outside of re-running the simulation from
frame 1.

A reconstruction of that magnitude appears to be way beyond the ken of
deformVerts(). At best, it can flag the condition of missing hair
particle pointers (psys->recalc |= ID_RECALC_PSYS_RESET), and
downstream, in the call to particle_system.c:particle_system_update(),
a brand new M X S+1 array of point caches are allocated by
particle_system.c:hair_step(). But these have no history; they
constitute a 'tabula rasa' of hair dynamics. The significance of this
clean slate becomes manifest in cloth.c:clothModifier_do()[3] which first
checks for the existence of pre-cached dynamics, and, in the absence
of such, attempts to run one step of the simulation. This, of course,
is a step from an initial state, and in the longer run, the simulation
is one of so many initial steps from just-initialized point
caches. This leads to the exact jerky character of the dyn_on.mkv
video, which appears to be a series of one-frame simulations.

Frame-to-frame dependency graphs updates occur in two contexts:
rendering, the consequence of CNTL F12, and view layer updates, the
consequence of running the timeline pointer forward. Each context
engenders dependency graph updates, the hairy details may be reviewed
by running the --debug-depsgraph command line option. I have not fully
cataloged the differences in these two contexts, but it is sufficient
to note, for purposes of grasping this bug, that in the context
of a view layer update, BKE_object_free() is not called. That is,
dependency graph updates appear to exhibit a little more finesse when
it comes to particle systems; a view layer managed dependency graph
update does not trash the particle systems at the the conclusion of
each frame render.

If my observations are correct, then, roughly, a fix for this bug
centers on aligning how the view layer does dependency graph updates
with how the rendering system does it. At present, the view layer
context handles particle systems with a bit more finesse than the
rendering context. The fix, I think, stems from exporting that finesse
from the view layer context to the rendering context. I don't have
grasp of what that entails in detail yet; I'm a new kid on the
block. But spring is coming in the Northern Hemisphere and the day is
still young.

------------------------
[1] These 'hair vertices' are not to be confused with mesh vertices. A
hair strand with N segments has N + 1 hair vertices with a 'root'
coincident with an interpolated position on a mesh face or a mesh
vertex of the 'parent' object.

[2] Not actually an array, as each row is a part of different
hair particle instance, but virtually an array.

[3] Hair dynamics is based upon a modified cloth simulation.