Doesn't the old method return string if the 1st arg is string? If so we can retain the same. We can use conditional return type based on argument type which keeps the return type deterministic for static analyzers.

Yeah, thats why the old code needed (array) casting.
These methods indeed are the 6.x code I recommended moving forward.
So those are already "clean" from BC requirements.
For the backport you are right, we probably should consider more BC approach.

Feel free to add a commit, not quite sure how that conditional works.

Why are we adding two new methods? We should pick one way to do this going forward that provides a more typesafe interface that handles several usage scenarios. I think drawing inspiration from classnames like @albertcansado suggested is an example of an ergonomic interface that could be hard to replicate exactly in typed PHP, but perhaps we can get close. Their docs have the following scenarios outlined:

classNames('foo', 'bar'); // => 'foo bar'
classNames('foo', { bar: true }); // => 'foo bar'
classNames({ 'foo-bar': true }); // => 'foo-bar'
classNames({ 'foo-bar': false }); // => ''
classNames({ foo: true }, { bar: true }); // => 'foo bar'
classNames({ foo: true, bar: true }); // => 'foo bar'

// lots of arguments of various types
classNames('foo', { bar: true, duck: false }, 'baz', { quux: true }); // => 'foo bar baz quux'

// other falsy values are just ignored
classNames(null, false, 'bar', undefined, 0, 1, { baz: null }, ''); // => 'bar 1'

In PHP I could see this constrained to:

function addClassnames(string $class, array ...$args): string

We can't give much type safety for args but I think that is on purpose. I think it is important to remember that most of the time classname manipulation is done to feed into another helper. Making it easy to dynamically generate class lists from a map of application state is an important scenario for server rendered HTML.

The PR above states the reason for the new IMO correct naming: They reflect what those separate methods now actually do, instead of the god method from before.

The change is fully automated via rector - and also fully BC.

If you have an alternative, go ahead. I don't see a good one at this point, though, that would replace the bad method with smaller ones, while keeping the upgrade efforts minimal.

Why are we adding two new methods?

Currently if you pass addClass() an array as the 1st argument, it treat it as a full arguments array and modifies $input['class'] and returns the array. How will we provide rector based automated updating if we only add new method which returns string?

That said instead of adding 2 new methods we can deprecate the ability to pass string as 1st argument to existing addClass() and also deprecate the ability to return a non-array value. So going future it would only deal with modifying a complete attributes array.

Then we add only 1 new method classNames()/addClassNames() would handles the actual CSS list merging which required API.