Cases like these where multiple impls on the same type and in the same file differ are generally incidental/accidental. Because of the inference implications I'm not sure if T-libs-api would merge a PR to relax the tighter impl(s) to match the looser impl(s), but personally I think that if someone cares enough, a PR would be warranted to figure out if the breakage is too much to justify just for the impl consistency. And if it isn't going to be changed, a comment indicating why they're different and pointing at the decision around breakage would be a good idea to save the next person who looks some time.
This kind of simple change is a great one to use to get initially familiar with the rustc build system enough to be able to check std changes locally, if you're interested in making code contributions to std. (And if you're not, that's perfectly fine too![1] If you want to assist but don't want to bother with making source changes yourself, actionable issues of "here's an oddity which should ideally get a fix or comment to say why" are generally appreciated and can be used to help onramp other devs who do want to try out code contributions.)
There's a fine line between welcoming contributions and "fix it yourself then" that I never quite know how to walk. ↩︎