Similarly named SMB share on Windows 10 is considered to be the same share

This is unfortunately how the Windows kernel SMB client works. I wasn't sure if anything had changed here recently and so I was providing an opportunity to provide a pcap if there has been a behavior change. The abstract data model for an SMB client from MS-SMB2 may help understand some of what is going on client-side: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/664ec686-fd6b-43e9-85da-5177d1f5453a

My guess is that Windows keeps a lookup table for open SMB sessions that is keyed-off of whatever you use to connect to the server (name, ip address, etc). The general response in File Explorer when it receives STATUS_ACCESS_DENIED is to pop up a password prompt. So when you type in \\server\share1, windows will check the session table for "server". If it exists, then it will use that to perform an SMB "tree connect" to SHARE1, if it doesn't exist, then it will go through steps to create a new session. You then try to connect to \\server\share2, it looks up the session and uses that for a tree connect to share2. If it fails with STATUS_ACCESS_DENIED (due to ACL issue for instance), then Explorer presents a password prompt. There's not much that we can do here because we don't control the client.

Yes, on Windows you can only be using one set of credentials at a time per server per session.

This is especially annoying when I have an Admin-only share and have previously connected using a normal user account; Windows will refuse to "reconnect" using different credentials until I've disconnected all other shares on said server.

It certainly makes for some interesting WTF moments...

I can't see your screenshots, but I think you're just running into poorly worded Windows error message. My understanding is that Windows requires you to use the same credentials for all shares on a server. If you try to use different credentials, the error message makes it sound like the share is already mapped, but it really means that you are already connected to the server. You can work around it by using any other name that points to the server (including an IP address) when setting up the second connection.
https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/cannot-connect-to-network-share

I see same behavior on shares on Windows Server 2016. If you see something different, please install wireshark on the windows client and generate comparative PCAPs for our Samba server vs a Windows server.