@Ladsgroup pointed out in a comment on I154d9cdebe that ConstraintParameterRenderer and ViolationMessageRenderer could get an IContextSource injected (or, more generically, any MessageLocalizer?) and use its msg function instead of using new Message() and wfMessage() directly. I’m not sure if that has any concrete advantages, but it sounds good to me.
So the reason I made MessageLocalizer is that we wanted to inject RequestContext somewhere just to use the msg method and @daniel pointed out that this class is a huge kitchen sink that are dragging around. That interface is an attempt to decouple RequestContext and message localization. In my ideal world, core would implement a proper RequestBasedMessageLocalizer and we would only inject that but for now I think injecting RequestContext instance using MessageLocalizer typehint (so we can easily mock it in tests, etc.) would be enough for me.
@Lucas_Werkmeister_WMDE The rationale for changing code to use narrow interfaces where possible is top remove circular dependencies to enable modularization. Currently, MW core is a tight knot of cross-dependencies, and kitchen sinks like IContextSource and "smart" records like User and Title are the main reason for that.
So, changing from IContextSource to MessageLocalizer contributes general code hygiene. The advantage is mid-term improvements of code quality.
@Ladsgroup: I don't see a need for RequestBasedMessageLocalizer. It's fine to use a RequestContext as the concrete instance, the code just shouldn't bind to that class (or the IContextSource) any more. RequestContext can be deprecated and replaced when nothing hints against it any more.