package.provided accepts only atoms that are not preceded by an equal sign, so that should equally apply to all its other inputs, whether command line, configuration files or ebuilds. Currently, passing an atom with a version but without [<>=] returns an error.
This is doable, since there is no ambiguity. PMS guarantees that there is no ambiguity because it forbids package names that have a version-like suffix (this part of the spec was tightened for bug 174536).
I do not think it reasonable to relax Portage behavior here. The long-term mixing of different syntaxes has already resulted in absurd requirements in the PMS. We oughtn't use those requirements as an excuse to make things worse again. Especially that providing a valid input is not an issue. If at all, we should strive to finally get rid of those requirements and be able to follow upstream naming independently of whether the author did consider that his name may accidentally match one of the very complex Gentoo version naming rules.
(In reply to Michał Górny from comment #2) > I do not think it reasonable to relax Portage behavior here. The long-term > mixing of different syntaxes has already resulted in absurd requirements in > the PMS. We oughtn't use those requirements as an excuse to make things > worse again. Especially that providing a valid input is not an issue. Removing the ambiguity was precisely the argument that was used in bug 174536 for tightening the requirements on package names (while I was much in favour of loosening them, see attachment 300745 [details, diff]). So it is only logical that Portage should follow up to this now. If that is not going to happen, then there is no reason for the current PMS wording that package names "must not end in a hyphen followed by anything matching the version syntax".
