Currently, when using a custom 404 page (e.g., 404.html), Firebase Hosting always responds with a 200 status code, even when the page is served via a rewrite rule.
This differs from behavior on traditional servers (e.g., Nginx with the internal directive), where the server can correctly return a 404 while still serving a custom error page.

Why this matters:
- Proper HTTP status codes are essential for SEO.
- Search engines may incorrectly index 404 pages if they return 200.
- Client applications and monitoring tools rely on correct status codes.

Additionally, In many multilingual or multi-section sites, different parts of a website require different 404 pages.
At the moment, the only workaround is to use rewrite rules, such as:

{
  "rewrites": [
    { "source": "/es/**", "destination": "/es/404.html" }
  ]
}

However, this still returns 200 instead of 404, which causes the same issue as above.

Requested enhancement:
- Allow developers to define multiple 404 handlers depending on URL patterns (e.g. /es/** → /es/404.html, /fr/** → /fr/404.html)
- Ensure each of these handlers can return a real 404 status code

These two capabilities would significantly improve:
- SEO accuracy
- Error analytics
- User experience for multilingual or multi-section websites
- Parity with traditional server behavior

Thank you for considering these enhancements!