Should HSTS Preload List affect unqualified hostnames?

Issue description

agl@, rsleevi@, thoughts on this one?
In Chrome 63, we added *.dev, *.app, *.page, *.foo, and *.chrome to the HSTS preload list.
Perhaps surprisingly, the dotless (“plain hostnames”) http://dev/, http://page/http://app/http://chrome/ and http://foo/ are all impacted by new HSTS rules as well.
We probably should not apply HSTS preload rules to these unqualified hostnames to avoid breaking users' Intranet sites. However, we may want to allow individual sites on unqualified hostnames to opt-in to HSTS via the response header.

I feel this is working as Intended. Such intranet sites are themselves broken by virtue of ICANN's policies around delegating them in the first place. We also have in place the ICANN transition to warn users, particularly for cases like http://foo.dev
Unqualified hostnames should never be able to opt-in to HSTS. As a result of ICANN's policy decisions, unqualified hostnames are effectively 'squatters', and should be considered deprecated and, as captured in SSAC policy, a security risk.

In order to avoid confusion, when writing HSTS names I write, say, (*.)dev and (*.)app in order to try and convey exactly what is covered.
I think I agree with sleevi here that these are now global names and we shouldn't pretend otherwise.