Hi, I'm experiencing this same issue, and I think I know the cause in my case (though I'm unsure of how to solve it). In my case, it is caused by having added these commands to keybindings.json in order scroll through lines visually when single lines are split via word wrapping.

  {
    "key": "up",
    "command": "cursorUp",
    "when": "editorTextFocus && vim.active && !inDebugRepl && !suggestWidgetMultipleSuggistions && !suggestWidgetVisible"
  },
  {
    "key": "down",
    "command": "cursorDown",
    "when": "editorTextFocus && vim.active && !inDebugRepl && !suggestWidgetMultipleSuggestions && !suggestWidgetVisible"
  },
  {
    "key": "k",
    "command": "cursorUp",
    "when": "editorTextFocus && vim.active && !inDebugRepl && vim.mode == 'Normal' && !suggestWidgetMultipleSuggestions && !suggestWidgetVisible"
  },
  {
    "key": "j",
    "command": "cursorDown",
    "when": "editorTextFocus && vim.active && !inDebugRepl && vim.mode == 'Normal' && !suggestWidgetMultipleSuggestions && !suggestWidgetVisible"
  },

It's strange. This issue happens because when doing a one-character replace with r, VS Code/Vim is still in NORMAL mode. If there is any way to detect whether it is currently in "one-character replace" mode, then this could easily be fixed.

This issue happens because when doing a one-character replace with r, VS Code/Vim is still in NORMAL mode.

I had the same problem. I looked at the code base a bit. The issue is that when we press r here we don't edit the state, while for example when we press R we do (see here).

If there is any way to detect whether it is currently in "one-character replace" mode, then this could easily be fixed.

Exactly, ideally after we press the first r we should edit the state. E.g. vim.singleReplace == true.