Do you think the Alt-Svc scenario we are talking about would guarantee two separate HTTP/2 connections?
Yes, the server can ignore both and always start a new session. And you could modify a client to never send either, but if you are already modifying the client code you could also modify it to always use a separate connection.
> HTTP/2 over cleartext TCP is also possible?
In theory yes, in practice most will only implement it over TLS, to avoid middleboxes breaking it. TLS-intercepting middleboxes won't negotiate HTTP/2, so it'll fallback cleanly in that case.
> Do you think the Alt-Svc scenario we are talking about would guarantee two separate HTTP/2 connections?
Alt-Svc to a different hostname will always use TLS. From the draft: "Clients MUST NOT use alternative services with a host that is different than the origin's without strong server authentication; this mitigates the attack described in Section 9.2. One way to achieve this is for the alternative to use TLS with a certificate that is valid for that origin."
And with current TLS, the hostname is sent on the handshake (SNI), so it can't use the same session for different hostnames.
Is there anything we haven't discussed that would fall within the HTTP/2 spec's "Reusing connections for different origins allows tracking across those origins." warning?
On the flip side, the use of TLS means that connections to different origins must be kept separate, even with Alt-Svc. If I'm reading https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-06 correctly, "example.com" MUST present the certificate for TopLevelOrigin1 or TopLevelOrigin2, which obviously requires a separate TLS handshake and thus a separate TLS session for each one.