That can happen when the InterpolatedStates buffer is activated but not updated (setting Space.BufferedStates.Enabled to true automatically sets Space.BufferedStates.InterpolatedStates.Enabled = true).
Calling Space.Update() with no dt parameter performs one time step and does not tell the interpolated states buffer to update because there is no time remainder. Calling it on every time step just to rebuild the buffers would also add in overhead if someone wanted to use Space.Update() to perform external time accumulation and time stepping while calling Space.BufferedStates.InterpolatedStates.Update directly. Calling Space.Update(dt) will update the interpolated states automatically.
So I'm in a bit of a pickle. I don't like the fact that this unintuitive failure mode exists. I could change the default behavior for enabling the buffered states to not also turn on the interpolated states. When interpolated states are disabled, an entity's InterpolatedStatesAccessor passes through back to the entity's direct, unbuffered properties. In order to use interpolated states, this would require an extra line to activate the Space.BufferedStates.InterpolatedStates directly. On the other hand, this situation might not be common enough to warrant that kind of sneaky breaking change.
I think I'll err on the side of doing nothing for now; if you or anyone see some compelling use cases where changing this seems appropriate, let me know. Until then, activating interpolated states only when either using Space.Update(dt) or Space.Update() with forced interpolated states updates is recommended.
Thanks Norbo. It's no big deal and your recommendation is fine, so I would also prefer you doing nothing so as not to unknowingly break something else.
I just thought I would point it out in case it was something not known about.