Personally I wouldn't merge this PR: this serves no practical purpose to me. I understand the motivation: InputBag represents values that can be found in request payloads, and these can only be strings or array of strings. InputBag in its first merged version allowed only strings|null. Then ppl reported that before InputBag was introduced, we used a ParameterBag, and this one allowed any kind of values. We thus made InputBag a bit more open and allowed all scalars (which Stringable is a kind of). When we did so, we preserved the original motivation for introducing InputBag (properly dealing with array inputs vs non-array ones) without breaking BC too heavily.

To me, this ship has sailed: yes, we could deprecate all non-string values, since none of them are possible values in raw HTTP. Yet, this would plan for a BC break that I don't see the value of.

Then, my recommendation would be to deprecate this class altogether as it's not about HTTP anymore, it's just a bag of things.

Deprecating InputBag would require us to use ParameterBag, which is even less strict. The reason why we introduced InputBag was to behave properly when ppl submit foo[]=123 instead of foo=123 in the query string. This reason still holds true and InputBag handles the situation as we want it to do.

Another idea might be to deprecate the $default arguments, since it's not needed anymore with the ?? operator. But honestly, I don't feel like this is worth it...

To me, #46957 is all that we need on this topic: it fixes a badly removed BC layer.

While working on this, I felt this it is not worth the noise it does. I agree with Nicolas we'd probably better not change anything

Let's close then :)