Vim: Ctrl-based combos stopped working unless `vim.use(…)` condition is removed from When expression

Describe the bug

Ctrl-based normal mode commands, such as <C-r> for redo, suddenly stopped working unless I delete && vim.use(…) part from each mapping’s When expression.

Seems to have coincided with VS Code and/or extension version update (which I was postponing).

I don’t remap keys and am using default combinations, so I don’t think this qualifies as remapping-related.

To Reproduce

Just try using ctrl+v for visual block selection, ctrl+u to scroll up, or ctrl+r to redo last undone change, etc.

Mostly nothing happens, though in case of ctrl+r I had VS command prompt pop up (which I think I map to something else anyway using VS keyboard shortcuts).

Expected behavior

Vim should handle those actions as per default.

Environment (please complete the following information):

• Extension (VsCodeVim) version: 1.17.2
• VSCode version: 1.52.0-insider commit 92192baf760315ac47fb2caaf3ce6d0778962352
• OS: macOS Catalina Darwin x64 19.6.0

Additional context

Seems to me that vim mode with default settings doesn’t handle those combinations anymore, apparently because vim.use() doesn’t behave as expected.

• Affected commands I had to fix so far in order to continue working
  • extension.vim_ctrl+r for redo (the first one I encountered)
  • extension.vim_ctrl+v for visual block selection
  • extension.vim_ctrl+u to scroll up
• Have Vim’s handling of ctrl-combinations enabled in the extension, as per default
• Am not specifying anything in handleKeys, so not delegating anything to VS Code
• Have exactly one custom vim binding, mapping <space>w to workbench.action.files.save, it’s been there for months with no issues

I just updated my Insider build after a week or more of postponing, so perhaps the issue was there for days by now.

Coincidentally, I used remote development over SSH today for the first time, but I didn’t need to change mappings or Vim extension settings so don’t think it influenced anything (VSC had been restarted since then and this bug occurs during usual local development).