Yep, this is totally surmountable IMHO, and it really just means we have to expand the semantics and syntax of wheel file field that is currently called “build tag”. A build number is a discriminator tag and a variant hash is a discriminator tag, so it seems like a simple matter of expanding the definition of the file name format.
Although of course it won’t be simple: it’s possible tools today do take the narrower current definition and if they e.g. validate that field, variant discriminator tags will fail to validate. I still think using the field-currently-known-as-build-tag is a reasonable approach, but the future PEP should call this out.
I am the FLUFL and Breaker Of Things! 
Yep, and that’s actually fine. For reproducibility (see e.g. the lock file thread) as long as the current variants.toml file yields the same results even if new packages are uploaded with different variant matrices, then I don’t think it’s too much to ask a user to update that file if needed. Perhaps a tool could issue warning and/or link when fallbacks occur.
On the lock file interoperability - I think that if you wanted to reproduce your environment, the combination of your lock file and your variants file would be sufficient, but you do need both (and hopefully nothing else).