Oh; in that case, I was confused as to why you were recommending that the user use tool.setuptools.dynamic.license = "..." and adding license to dynamic instead of just doing project.license.text = "...", unless you had deliberately not implemented the functionality of the license key.
This is not the intended behavior specified by PEP 621, as the License-File field didn’t even exist when PEP 621 was created, it is introduced in the still being finalized PEP 639. Rather, as I explain above, what appears to be intended is for file to specify a file whose text is dumped into the License core metadata field, much like the file prefix in setup.cfg (which is also why it is mutually exclusive with text). However, it certainly is very understandable that you interpreted it this way, as PEP 621 is very vague, underspecified and ambiguous on this point and in no way states this explictly. In fact, despite pouring over that PEP and many others multiple times, as well as various implementations, I myself was confused on that point until very recently.
Yes, it is a different behavior, but @kkrolczyk is expecting is the behavior intended by the specification in PEP 621. There is not yet a standardized License-File or License-Expression core metadata field, but having License-File contain a value but License/License-Expression not is perfectly valid (though specifying both of the latter is an error), and would be desired in some cases (e.g. non-SPDX license). The converse case for Core Metadata 2.3, where License-Expression/License contains a value but no license files are specified/found, is technically valid (i.e. the standard currently doesn’t prohibit it), but should not normally happen (and it is specified that it should generate a warning due to no License-File entries being found, regardless of License-Expression/License field status).
Regarding Setuptools’ and Wheel’s non-standard use of License-File, they are using them roughly following a previous draft of the yet-unstandardized PEP 639, but the semantics have changed somewhat in the current version, and could change further before final acceptance. As such, we cannot condone this behavior, though so long as they do not actually increment the metadata version to 2.3, it is still possible to retain backward compatibility without affecting packages produced with these existing non-standard extensions, and the specification in the PEP explicitly ensures that future tools conforming to it will not assume the standard semantics in older non-standard fields.