Ho capito cosa intendi, ma io non parlavo dell'URL ricevuto dal controller (o dal router per smistarlo al controller stabilito), che è un identificatore della risorsa interno all'applicazione, ma parlavo dell'URL che l'utente invia all'host.

Posto che una modifica del REQUEST_URL (l'URI senza query string) di una risorsa deve causare un 404 se non individua alcuna risorsa, il quesito che mi ponevo era invece proprio sulla modifica alla query string o all'invio di parametri POST non abilitati dall'applicazione

Il fatto che in questo caso i CMS più diffusi restituiscano lo stesso codice di stato senza filtrare i parametri GET/POST ma accettando tutto, conferma il mio dubbio iniziale che il 404 sia un po' eccessivo...

Comunque leggendo la descrizione del codice di stato 202 di cui tu parlavi mi sembra che possa essere un valido responso per casi simili, ovvero: l'URL contiene parametri GET o POSTDATA non amessi -> l'applicazione accetta ugualmente la richiesta, riservandosi però il diritto di non completare la sua elaborazione.