openssh-win32 fails randomly when using local groups for "Match Group" settings

Note that in all log entries, the user used is a local user "testsftp", using password authentication. The user is a member of the group "sftpcommonjail", but not "administrator".
With two "Match Group" entries in sshd_config:

Match Group sftpcommonjail
ChrootDirectory F:\jail
Match Group administrators
AuthorizedKeysFile PROGRAMDATA/ssh/administrators_authorized_keys

"OpenSSH for Windows" version
7.7.2.2

Server OperatingSystem
Windows Server 2019 Datacenter

Client OperatingSystem
Windows Server 2019 Datacenter (same server as above)

What is failing
When "Match Group" is used in the sshd_config, sftp connections will randomly either work, get connection reset by peer, or say invalid password.

Expected output
When it occasionally works, I get the output below:
5516 2021-08-11 16:38:20.812 debug1: user testsftp matched group list sftpcommonjail at line 97
5516 2021-08-11 16:38:20.812 debug1: user t does not match group list administrators at line 109
5516 2021-08-11 16:38:20.812 debug1: userauth-request for user testsftp service ssh-connection method keyboard-interactive [preauth]
5516 2021-08-11 16:38:20.812 debug1: attempt 1 failures 0 [preauth]
5516 2021-08-11 16:38:20.812 debug1: keyboard-interactive devs [preauth]
5516 2021-08-11 16:38:20.812 debug1: auth2_challenge: user=testsftp devs= [preauth]
5516 2021-08-11 16:38:20.812 debug1: kbdint_alloc: devices '' [preauth]
5516 2021-08-11 16:38:21.375 debug1: userauth-request for user testsftp service ssh-connection method password [preauth]
5516 2021-08-11 16:38:21.375 debug1: attempt 2 failures 1 [preauth]
5516 2021-08-11 16:38:21.375 Accepted password for testsftp from ::1 port 53530 ssh2
5516 2021-08-11 16:38:21.375 debug1: monitor_child_preauth: testsftp has been authenticated by privileged process

Note that the username gets rewritten to "t" in the second line. Based on the behaviour, it looks like the process checks against the name it gets from the previous step before it somehow mangles that variable, prints it and then the next step uses it.
This is consistant with examples below from where it's failing.

Actual output
When it fails with.
Connection reset by ::1 port 22
Connection closed
The log seems ok.
3680 2021-08-11 16:38:17.761 debug1: user testsftp matched group list sftpcommonjail at line 97
3680 2021-08-11 16:38:17.761 debug1: user testsftp does not match group list administrators at line 109

But when it fails with permission denied, it looks really bad:

5876 2021-08-11 16:33:51.934 debug1: user C:\Users\testsftp matched group list sftpcommonjail at line 97
5876 2021-08-11 16:33:51.934 debug1: get_passwd: LookupAccountName() failed: 1332.
5876 2021-08-11 16:33:51.934 debug1: Can't match group at line 109 because user n does not exist

3160 2021-08-11 16:33:58.567 debug1: user n matched group list sftpcommonjail at line 97
3160 2021-08-11 16:33:58.567 debug1: get_passwd: LookupAccountName() failed: 1332.
3160 2021-08-11 16:33:58.567 debug1: Can't match group at line 109 because user n does not exist

2996 2021-08-11 16:37:35.244 debug1: user t matched group list sftpcommonjail at line 97
2996 2021-08-11 16:37:35.244 debug1: get_passwd: LookupAccountName() failed: 1332.
2996 2021-08-11 16:37:35.244 debug1: Can't match group at line 109 because user t does not exist

In a previous test, I also got this:
6736 2021-08-11 15:46:05.429 debug1: user test_sftp_pw matched 'User test_sftp_pw' at line 88
6736 2021-08-11 15:46:05.429 debug1: user test_sftp_pw matched group list sftp_common_jail at line 96
6736 2021-08-11 15:46:05.429 debug1: user \001\002 does not match group list administrators at line 108

I have no idea why it replaces the username with "t", "n", "C:\Users\USERNAME" or even "\001\002" when checking them against groups, but it's probably related to why it randomly fails, or rather, randomly occasionally works.

As a workaround, I'm able to remove all "Match Group" entries, replacing them with multiple "Match User" instead, but as you can imagine, that's not even close to practical to scale.

Reproduce the issue on Windows Server 2019 with the shown sshd_config, local user, and Match Group entries, then compare the debug logs from successful and failed connections. Trace the Windows OpenSSH handling of the username during group matching; done means the username remains valid, group matching is consistent, and password-authenticated SFTP connections no longer fail randomly.