As noted in an inline comment to the introductory PR: Why force the control to have shrunken text? In the case of an endAdornment specifically it seems to be to be more consistent to not force shrink. I did some CSS-hacking to screenshot this:

If a user has trouble with it not being shrunk he or she can simply add the shrink attribute to the InputLabel, but I've not found an easy way to unset it when core sets it.
@kf6kjg I have been asking this question too. I have decided to be lazy and see if the issue would be raised. Well, it's the case. Do you want to change the adored logic so we only use the start property into account?
WIP :P
I thought about this with the initial implementation and decided that the safer option from a library point of view was to shrink everything as the label could overlap the end adornment especially with localised text in a responsive environment leading to a poor user experience but I also understand the desire for a label to not be shrunk when no overlap occurs but I can also gaurentee we will end up with an issue when a long label overlaps an end adornment and need to start measuring the label to decide if we shrink or not..
@eyn Good analysis, there are limitations with both solutions. Still, I think that @kf6kjg solution has a better recovery story.
@eyn Agreed, however as @oliviertassinari pointed out the user can recover by doing as they will. Also overly long text has other issues too:

Another way the user can fix it is by doing other CSS tweaks, like limiting the width of the label or adding a margin, etc.
@oliviertassinari @kf6kjg totally happy with the change - agree its easier to add a shrink property if you want to keep the current behaviour and have the nicer behaviour by default
As noted in my commit comment:
This was not done with the startAdornment for two reasons:
Thus I'm open to suggestions.
I kinda bumped into the same issue

It feels weird that it's forced without an option to override it. And I can't find any ways to hack it around. Would it be possible to have something like auto value for shrink so at least I could explicitly say that for my case I WANT it to be automatically handled?
@oliviertassinari @eyn ?
@bytasv We are continuing the discussing in #14119.
Most helpful comment
@eyn Good analysis, there are limitations with both solutions. Still, I think that @kf6kjg solution has a better recovery story.