The fix of MC-152728 has indirectly made it so your ctrl sprint input buffer is not regained after completing an action that slows movement (such as crouching/shielding/eating).
Expected Behavior: Ctrl sprint input is regained after the slowdown action is completed.
Observed Behavior: Ctrl sprint input is lost after the slowdown action is completed, forcing a new sprint to have to be manually started.
Attachments
Comments
migrated
Viradex
Can confirm.
clamlol
A better way to phrase this would be to say that when a sprint is canceled by a self-inflicted moment-slowing effect, it is not auto-reactivated when the effect ends. I'm personally of two minds about this behavior. On the one hand it makes sense since other means of canceling sprint have always worked this way. On the other hand you could argue that self-slowing effects constitute "temporary sprint suppression" and deserve special treatment. Certainly the appeal of hold sprint (as opposed to toggle sprint) will take a significant hit if this change is considered intentional behavior.
For what it's worth, I personally would like to see a fundamental re-evaluation of sprinting in Minecraft. I'm not aware of any other video game which incentivizes the player to sprint almost all the time like Minecraft does; more typically, sprinting is reserved for those situations where the player wishes to sacrifice combat readiness in order to travel a bit faster. If players expect to be able to travel at sprinting speed all the time it may be desirable to make sprinting the default and lock walking behind a toggle/hold button (or remove walking altogether); this would also eliminate the frustration caused by toggle sprint not activating after death (MC-263293) and after login/dimension change.
(Edit: updated the issue title to make it a bit clearer.)
rkullenius