If you're putting variant.json files in the files section of the JSON response, then you need to follow the existing rules, which say that for each files entry, filename, url, hashes and size are mandatory, and all other keys are optional. There's nothing in the existing spec that suggests that tools can ignore attributes if they are present, and I don't think we should be special-casing variant.json files.

I actually don't understand why you're allowing these fields to be present at all. What's wrong with simply saying that variant.json files must not include any of the optional fields defined in the index spec (with the exception of the upload-time field, which may be present)¹?

Honestly, this feels like a problem caused by trying to put variant.json files into a field that's intended to hold details of distribution files. I'd argue that a cleaner design would be to have a separate variant-data field in the project details response².

Yes, "optional fields" is what we meant. We'll correct this.

For the rest, see rationale. The goal is to support indexes during the transitional period with minimal modifications necessary. Should the tools be rejecting projects if the index gives unnecessary-yet-harmless fields?

Specifically note the provision:

Indexes MAY publish or skip these attributes, as long as the values do not prevent correct operation. Tools MAY either use or ignore these values.

This is intended as "you don't have to go out of your way to special case that one file", as long as you don't do something really wrong there.