For all of its warts, HTTP is essentially a single protocol; if you see 'http://...', you know what pretty much anything will do with it, and they're all going to do about the same thing. This is not the case for HTTPS. HTTPS looks like a single protocol, invoked by 'https://....', but it's really a bunch of protocols all dumped in a big sack labeled 'HTTPS' on the outside. The actual protocol that clients will use for HTTPS URLs can vary widely.

Some of these protocols are closely related to each other, like the HTTPS protocols that are all some version of TLS over TCP with plain HTTP/1.1 spoken over the encrypted channel. Even there there's divergence between clients; your old program may talk TLS 1.1, my somewhat more recent one is TLS 1.2, and web browsers are TLS 1.3. Others are not as related; there is HTTP/2, which still uses TLS over TCP as a transport protocol but has a quite different thing inside the encrypted channel. And lately there is the pretty divergent HTTP/3 (also known as HTTP3), which changes the low level transport protocol to QUIC, which means that its traffic uses UDP instead of TCP.

(Using UDP instead of TCP matters because there's a host of differences in how IP networks handle them.)

What this means in concrete terms is that if you put a https: URL into two browsers or more generally two clients, how they talk to the server may be completely different. Since they're different, especially HTTP/3, one way may work and the other way may fail. Naturally this complicates troubleshooting, especially since most browsers and programs don't tell you what sort of HTTPS they're actually using.

(If you're not up on the latest web developments, it may not even occur to you that there are multiple types of 'HTTPS' out there.)

There's a straightforward but unappetizing reason for this, which is that there's essentially no chance of HTML having an additional URL scheme such as 'http3'. Since we're stuck in a world where the only two URL schemes are 'http' and 'https', everything must be called 'https' regardless of what its actual protocol is (provided that it's encrypted with something that's at least called TLS).

(For similar reasons, all future server certificate and public key based encryption schemes used for web traffic are likely to be called 'TLS'. Sadly, they will probably have to look like it from the outside because of an excess of middleware boxes that think they know what TLS handshakes look like and reject anything that's too divergent.)