Thanks for the comments. For context (which I should have included initially), this task was borne out of a conversation between me, @aklapper and @valerio.bozzolan about which parts of a downstream hack I was working on (https://phabricator.wikimedia.org/T393289) could be useful upstream. If the answer is "none", I can live with that.

1. see parent task
2. This wouldn't actually help the described use-case anyway.

(see parent task - I'm against this).

I have not a strong opinion about author usernames (T16052) but if you say to decline that makes sense, especially if at least as small compromise we simplify bot recognition, T16051 and D25987, so that local installs can rewrite their UX without completely nuking their past history and doing complicated comment→transaction migrations on past data.

I suggest testing by setting window width = 1791px (e.g. CTRL+shift+M on Firefox), and then passing to window width = 1792px. So we can see that the content max width at the moment always seems ~ 800px.

Uhm - but looking at your screenshot, at looking here T15920, it seems a regression

Patch welcome, with "Ref T15920"

When reading the wiki at a resolution of 3440x1440 (34 inch monitor), there is still a lot of white space.

Feel free to throw the patch as-is, as I usual I love to cleanup and test more loool

I have a patch ready, need to clean up and test more

To put it another way:
I think the described use-case is too narrow, and a naive expansion of the use-case isn't scalable.
The described use-case fails for at least one possible use-case ("some bots have something useful to say").

Personally I'd decline T16052 (data duplication) and I do not yet see a need for potential new transaction types either (a comment is a comment is a comment no matter who/what made it).

Yes, this is where my first comment enters - I feel this is a rabbit-hole we shouldn't venture into, etc.
The current script appears to have 3 names, and referring to "legacy data" implies that there won't be any new names to add.

If you mean this kind of hardcoded CSS rules, yes, it's possible for local installs:

the legacy data can be handled by the already-existing hard-coded names...

Yessss, I agree and we explored a bit the creation of new transactions as good long-term direction, unfortunately it seems still necessary a bit of CSS help from the backend to cover the legacy data (e.g. 10 years old bot-generated comments, with traditional comments)

I feel this is a rabbit-hole we shouldn't venture into.
The slippery-slope argument will make us adding a custom class for each individual user, so css extensions can be used to hide/highlight comments from boss/intern/etc.
It's also probably not enough to remove the hard-coded requirement either - in some environments, one "bot" user is copying comments from another platform, and another is making statistical updates about a jira ticket, so you'd still need a better filter.