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 onlystrings|null. Then ppl reported that beforeInputBag was introduced, we used aParameterBag, and this one allowed any kind of values. We thus madeInputBag a bit more open and allowed all scalars (whichStringable is a kind of). When we did so, we preserved the original motivation for introducingInputBag (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 submitfoo[]=123 instead offoo=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 :)