Thank you for this PR.

Could you elaborate a bit on the use case or the scenario where you need getAny()?

Sure

1. I currently use ParameterBag for json input (cf. example), having a get to force strings is a good idea so I would be keen to use InputBag but for that I also need to be able to "get any" (for example I have some fields where it can be an array or a value)
2. I think it would be easier for devs to migrate, ->get() can be replaced with ->getAny()
3. Having ->get() which returns any type in ParameterBag and ->get() returning string only in InputBag is a bit strange because it creates a discrepancy and Symfony devs are used to have ->get() for anything and ->getInt/Alpha/etc.() for "filters"
   1. Which makes me think, wouldn't it be better to have ->getString() to get string and ->getAny() for anything in ParameterBag ? It would be more explicit

Example in my request:

        if ($this->isJson() && $content = $this->getContent()) {
            $this->request->replace((array) json_decode($content, true));
        }

$this->request->replace((array) json_decode($content, true));

Thanks for the explanation, that helps a lot to get your pov.
Honestly, I'm not convinced this is a legit design for JSON query arguments.
I would recommend putting the decoded JSON into a request attribute instead.

getAny() is reopening the trap we wanted to close when adding InputBag: contrary to what you describe, we started with the pov that 99% of the use case for get() is retrieving strings since that's what a query string contains at the origin.

I'm 👎 on my side with this reasoning.

Thank you for the context.

I like the implementation and the fact that you added a test. 👍 However, it is a good thing that you know the type of the return parameters.

I also thing we should close this PR.

Okay got it, thanks for your feedbacks !

And what do you think about introducing a getString() in ParameterBag ? I think it would make sense to match getInt/Alpha/etc., to have something more explicit and usable in ParameterBag + InputBag without discrepancies

You might be interested in having a look at #37100 (comment)