> I'm guessing this is some unintended consequence of replacing
> read-char-choice in userlock.el with read-char-from-minibuffer.
>
> Juri, could you please look into this regression in Emacs 27?  I'd
> like to try to fix this for 27.2.

Here is a brief trace that explains the cause of the problem:

1. C-y (yank) calls delete-selection-pre-hook from pre-command-hook
2. delete-selection-helper calls delete-active-region
3. this activates ask-user-about-supersession-threat on a modified file
4. it calls read-char-from-minibuffer ('this-command' is still 'yank')
5. read-char-from-minibuffer waits when user types 'y'
   (bound to the command 'read-char-from-minibuffer-insert-char')
6. after typing 'y', read-char-from-minibuffer returns 'y', but
   now 'this-command' is 'read-char-from-minibuffer-insert-char'
7. when delete-selection-pre-hook finishes, due to 'this-command'
   'read-char-from-minibuffer-insert-char' is called again,
   and this time operates on the buffer as if it's the minibuffer

It seems there is a fundamental problem when read-from-minibuffer
is used from pre-command-hook it modifies the value of this-command.
But I wonder why this problem doesn't occur in other places.
Maybe other places doesn't try to operate on the buffer as on
the minibuffer?

Anyway, here is a patch with two fixes:
1. Guards read-char-from-minibuffer-insert-char against inadvertent
   operating on the non-minibuffer buffer;
2. Prevents read-char-from-minibuffer from changing the value of
   'this-command' by read-from-minibuffer: