Idea Summary
Rel 22.2 App Builder Users Guide Chapter 3 Table 3-1 states that itemValues that are
passed may be encapsulated by baskslashes e.g. \123,45
This mechanism is apparently used by Apex internally when I use the App Builder Feature
"Search this App for xyz,abc".
When I search for "xyz,abc" the following URL is created (and correctly processed:
https://apex.oracle.com/pls/apex/f?p=4000:8000:24827132777956::::P8000_START_SEARCH,P8000_SEARCH:1,\xyz%2Cabc
The comma is a URL reserved character and correctly encoded as "%2C" (presumably using APEX_UTIL.URL_ENCODE)

However the backslash itself is not a valid URL character (see RFC 3986 chapter 2)
The Web Server used by apex.oracle.com seems to ignore this issue and passes the URL on to ORDS / APEX.
The new browser window opens and everything works OK.

In our environement (compute server on OCI) we use tomcat 19 as Application Server.
This application server refuses to process the URL and I get HTTP Error 400
If I run ORDS in standalone mode, the request is processed OK.
If I modify the URL and encode the backslashes with "%5C" everything works with Tomcat as well:
https://apex.oracle.com/pls/apex/f?p=4000:8000:24827132777956::::P8000_START_SEARCH,P8000_SEARCH:1,%5Cxyz%2Cabc%5C

It is possible to get Tomcat to "tolerate" the backslashes, but I think that is a workaround at best
and may cause more problems down the road.

Use Case
Any scenario, where application servers are used that enforce strict adherence to HTTP/1.1

Preferred Solution (Optional)
I think that it would be best, if APEX were to encode the backslashes as the URL is being generated.
In fact the function APEX_UTIL.URL_ENCODE performs just this replacement for backslashes.
This should fix the problem, no matter how strict the application server validates the URL.