I did this

curl_easy_setopt(curl, CURLOPT_HTTP_VERSION, CURL_HTTP_VERSION_2_PRIOR_KNOWLEDGE); for an https URL.
The resulting ALPN extension still contained both h2 and http/1.1, and for servers not supporting HTTP/2, the handle falls back to HTTP/1.1 (both as if CURL_HTTP_VERSION_2 was used).

I expected the following

CURL_HTTP_VERSION_2_PRIOR_KNOWLEDGE should mean "HTTP/2 or fail" (TLS or no TLS). For TLS connections, this means ALPN extension should contain h2 only (no http/1.1), and if the server does not agree, then the transfer can fail immediately; or ALPN/NPN negotiation results can be ignored, HTTP/2 used anyway (as is over TCP with CURL_HTTP_VERSION_2_PRIOR_KNOWLEDGE), and transfer can fail at that stage. TBD which behavior is better; in theory since HTTP/2 servers are required to support either ALPN or NPN, then if they don't agree to h2 it can be assumed that HTTP/2 will not work; but in practice servers may be misconfigured at the transport layer, e.g. be behind a reverse proxy terminating TLS, but support HTTP/2 despite not advertising it.

curl/libcurl version

curl 7.79.1 (i386-pc-win32) libcurl/7.79.1 OpenSSL/1.1.1l zlib/1.2.11 nghttp2/1.46.0

operating system

Windows 10 21H1 amd64