Plan:
* Implement static function for NSS NPN callback in SSLClientSocketNSS to do what we want.
* Have two NextProtoVector members of SSLConfig: one for NPN, one for ALPN.
* Remove HTTP/2 from the NPN list for NSS.

This is fixed for OpenSSL. As for NSS (still used on iOS), however, fixing issue 538015 would have been too complex to be worth it, therefore on that particular platform, HTTP/2 is still used with NPN until the transition to OpenSSL.

This change will have the opposite effect of what is intended. A very large number of sites use Ubuntu LTS releases - currently that's 14.04 - which supports NPN, but cannot easily support ALPN. The next LTS release will be 16.04 - 6 months from now. FWIW it's not in Debian Jessie either, and that was only released a month ago.
Nginx 1.9.5 and up supports HTTP/2, but that will not ship as standard in Ubuntu until the next LTS release. 14.04 ships with OpenSSL 1.0.1f, which has NPN but not ALPN. Currently if you install nginx 1.9.5+ on Ubuntu LTS, you only get NPN support. It is of course possible to upgrade openssl without changing the OS release, however, openssl is depended upon by many, many other packages, and making this change would be unsupported and would result in unknown side-effects, so it's simply not going to happen at any kind of scale.
There's no need to "provide an incentive" - the next Ubuntu LTS release *will* include the necessary support for HTTP/2 with ALPN (OpenSSL 1.0.2d is already in Ubuntu 15.10), but the LTS release schedule is not going to change. Server admins are not going to switch to a non-LTS release with only 9 months of support for the sake of one or two packages.
HTTP/2 + NPN works in older versions of Chrome, but not in releases after this change, i.e. the only effect of jumping the gun like this this is to penalise Chrome users (especially those that update) by downgrading them to HTTP/1, and nobody else, which seems pretty obtuse.
Meanwhile, all other browser users enjoy better performance with HTTP/2 + NPN...