And here is my PR to change this: #49556

I don't think we want to make it private. The request property is a source of truth and should stay immutable. If you want to get the main request you have the getMainRequest function. What exactly is your need?

Changing properties to protected increases the maintenance cost a lot (because protected properties are covered by the BC promise).
So we won't do that without a good use case for which the protected visibility is indeed the right solution.

I don't think we want to make it private. The request property is a source of truth and should stay immutable. If you want to get the main request you have the getMainRequest function. What exactly is your need?

I need to extend the original RequestStack class to add some utilities like clearing all requests, getting the request by the count (eg, request #3).

"I need to extend the class" is not a use case. It is a solution that implies making maintenance harder. We need the use case, so that we can think about potential alternative solutions that would not require such cost.
Opening protected APIs is one of the highest maintenance cost we can add for a class (and protected properties are more costly than protected methods)

Thus, allowing child classes to alter the stack of requests directly might lead to weird bugs when that interacts with the logic in HttpKernel that maintains that stack for handled requests.

clearing all requests

while ($requestStack->pop());

getting the request by the count (eg, request #3).

If this is a thing, we could add an accessor for that or let you iterate over the requests. Can you elaborate why you need to access a request that is neither the current nor its parent nor the main one?

Note that by clearing all requests, you will probably break the integration with the HttpKernel (and cause weird bugs in the profiler for instance) as the stack would become out of sync with requests that are actually handled by the kernel. So clearly, this misses an explanation about why you want this clearing.

In the middleware function need to scan all previous requests and filter out some of them by the business rules, or clean all of them and insert a new "correct" one.

Yes, this looks is a very specific logic for my individual case, and changing private to protected could resolve the issue for me, just thought that it can be done easily on Symfony's side.

But if this change can cause a lot of other regressions, let's keep it as is, maybe?

And for my case, I can resolve the problem by copy-pasting the whole RequestStack class to my own one, and changing it, instead of extending the original one. Yes, that looks bad but seems now it's the only way.

In the middleware function need to scan all previous requests and filter out some of them by the business rules, or clean all of them and insert a new "correct" one.

I fail to see what that means. The requests in the stack correspond to nested requests (when a request triggers a subrequest that triggers another subrequest). They are not previous requests.

And this inserting of a "correct" one is probably flawed as well, as the HttpKernel would still be dealing with the request it received.
To me, this discussion highlights a big misunderstand of what the RequestStack is about.

Okay, this is my very specific case, so let's close the discussion.