Websockets and HTTP/2 have not much to do with each other. Both are established on top of a TCP connection (which might have been used to speak HTTP/1.1 before, until an upgrade occurred). Websockets allow sending unsolicited websocket frames in both directions, HTTP/2 multiplexes several HTTP streams on top of a single TCP stream.
There is no websockets over HTTP/2 specification- at least the last time I had looked. It wouldn't really yield much benefit, one would just have the 2 layers of framing (web socket framing on top of HTTP/2 framing). With the current approach one would typically just have 2 TCP connections established from a browser to servers, if websockets are needed: One for websockets, and one for HTTP[/2].
Regarding SSE: Use it when single directional communication is good enough, when HTTP based authentication is required, for integration with other HTTP infrastructure (load balancing, proxies, etc), or when no websocket library is available. Websockets might be mostly preferable when stateful "realtime" communication in both directions is required.
The kicker is if a client connects to you via HTTP/2, you can't upgrade/hijack that session to be a websocket stream since the underlying TCP connection could be being shared by(used to multiplex) multiple HTTP requests/sessions. You have to take care to make sure the request ingress path from the client to the app is HTTP/1.1 end to end. That is something that is getting harder to do. Browsers use H/2 by default, more and more CDN do, more and more middle-ware does etc. The draft RFC I mentioned is a websocket upgrade mechanism for HTTP/2.
I don't see an issue. If a browser wants to create a websocket connection, it will always create a fresh connection and do a HTTP/1.1 upgrade. Because that's the only way how websockets are specified.
On the server side most things are handled in the low-level HTTP handlers. There (e.g. in Netty/Jetty and Co) one needs to care about ALPN negotiation, websocket upgrades and Co. But higher up (J2EE, express, etc) things are mostly about HTTP semantics, and there isn't any handling about "upgrade" or even the "Connection" field in general anymore.
Yes, the line between HTTP application semantics and HTTP/1.1 transport is very thing and nobody exactly knows where things start and end. But I'm still not convinced we need web sockets over HTTP/2, e.g. in order to allow upgrades in the application layer.
