I see no reason why not. Tools can choose not to use packaging.pylock if for some reason they really don’t want to do that validation. The only reason I prefer SHOULD over MUST is to avoid making any existing tools that don’t validate non-compliant.
If the consensus is that we want to be strict here, we can do that by declaring that lockfiles where package.name and/or package.version are inconsistent with the filename are invalid[1]. That requires producers to ensure they don’t produce garbage, rather than requiring consumers to do the checking (but still noting that they should validate).
For version, the spec may already require this - it says that
versionMUST NOT be specified if it cannot be guaranteed to be consistent with the code. which seems to me to be a roundabout way of saying that if it is specified then it must be consistent ↩︎