For anyone who comes on this in the future, found a bit more…
Turns out there is some code in the character movement component specifically for processing async movement. I stumbled on this as I was going about learning how the movement component consumes inputs.
However, obviously per the comments around it, it’s an in-development feature that’s not ready yet.
I tried toggling this on, along with making my movement component register with the async physics system, and on first test, my movement inputs no longer worked, the character no longer had a recognizable movement mode, and I hit multiple ensures in code. So yeah, this is more unfinished than just an “experimental” feature, it’s just not done and probably not worth barking up this tree for now.
Another thing I learned in the process of digging into all of this is that I think a lot more would need to be rewritten for inputs to be processed in this async manner. It appears that delegate bindings in general run on the game thread, and the base and enhanced input system is obviously using those across the board to work at all. If your inputs are processed on the game thread, then it seems like their timing can get out of sync with another tick like this (i.e. late or early).
I toyed with processing inputs on this async tick, but that didn’t really work, can see the movement code already was trying to go down that route for the user.