In the Servlet API "request params" provide Map-like access to both URI query params and form data (parsed from the request body). The concept fits well in the Servlet API where "request params" are accessed in a blocking fashion whenever needed. It does not however fit with use of the Servlet 3.1 non-blocking I/O API which is mutually exclusive with any calls to get "request params" since those may block.
SPR-15000 introduced support for Servlet API style "request params" in WebFlux by parsing form data eagerly (without blocking) and then caching it. This was a reasonable trade-off for simple forms that made it feasible to support the concept of "request params".
SPR-14546 introduced support for multipart form data. A multipart request may represent a browser form with a file input field, or it be a non-browser client sending a request with potentially large parts of data of any media type. Support for "request params" is now a challenge. While eager parsing + caching multipart form data may be okay for browser forms (in combination with a max file upload limit) it precludes support for streaming large multiparts sequentially, something that is a natural fit for WebFlux, e.g. a Flux<Part> controller method argument.
This ticket is to remove the concept of "request params" from WebFlux in favor of the more explicit, existing support for access to query params vs form data. We can continue to support data binding of both URI query params and form data (including multipart data) to a command object (via @ModelAttribute). In WebFlux however @RequestParam or @RequestMapping(params="...") would have to refer to URI query params only. This trade-off seems a better fit for WebFlux.
In short the concept of a single bucket (Map) for something so disparate as simple URI query params on one end and very large parts in a multipart form data request on the other is just not feasible while also providing support for on-demand, non-blocking parsing of large content.