What if: We remove 404 error handling?

In fact, I would like to consider a different approach to handling 404 error.

By default, a 404 error caused by an exception uses the error_404 file to generate the error, and this file is in the application's views.
Currently, a developer can define a custom handler for 404 errors in routes. A handler can be a controller or a closure.

Why don't I like this.
1. The fact that the 404 handler is defined in the routes collection, although only indirectly related to routes.
2. The fact that the controller call is used, which obliges the handler to be inherited from the Controller class.

My suggestion.
Since @kenjis added in 4.4 the ability to define global custom exception handlers, I'd like to hear your feedback on the 404 error handling I'm proposing.

1. Make the error_404 view a system file, i.e. the developer will no longer be able to change it, but the framework will use this file by default.
2. Remove the ability to set a 404 error handler from the route. Instead, it will be possible to handle the exception through the new custom exceptions feature.

The current routes config (and implementation) is a bit odd as you say, but I have different opinions.

My modeling (to be, not as is)::
1. Router determines handlers (controller/closure)
2. Router has many Route Drivers (Defined  Routes Driver, Auto Routes Driver, ...)
3. A Route Driver, Defined Routes Driver has a Route Collection

The current route collection in the Routes file is the config for the Defined Routes Driver.
So the definition of 404 Controller is not a part of the route collection.

But it is not odd that Router has a 404 Controller that handles when no route found.

In my opinion, 404 should not be an exception. It is not an exceptional error,
but it is what is normally expected to happen.

The error_404 file should be located in app/, because it is very common that a dev wants to customize 404 view.
It does not seem worthwhile to complicate that customization.

2. The fact that the controller call is used, which obliges the handler to be inherited from the Controller class.

What is the issue on this?
$override404 is a controller/method name or closure.

ci-phpunit-test | CodeIgniter Testing Guide | CodeIgniter 3 to 4 Upgrade Helper

For a complete understanding, I will describe more globally. Maybe I wrote it, but I'll repeat it anyway.
To a greater extent, this is due to the centralized sending of the response and the inability to test exception handling.

In the code of the CodeIgniter class, we register exception and error handlers.

PHP Code:

// Setup Exception Handling
        Services::exceptions()->initialize(); 


But the error and exception handler does not return a Response. That is, we cannot test, for example, which headers have been set. And to get the response body, we need to capture the buffer.
Although it is possible to use the exception handler directly and force it to return a response.

PHP Code:

try {
// call request handler
} catch (\Throwable $e) {
    $response = Services::exceptions()->exceptionHandler($e);
} 


But since the 404 exception handler can be a class (controller), now we have to use a method to call the controller.

PHP Code:

$controller = $this->createController();
                $returned   = $this->runController($controller); 


If we abandon the current concept of the 404 exception handler and initiate processing through the functionality you added, then we will reduce the amount of code and improve testing.