We're running into the limits of the existing @php-wasm/logger system and need to revisit it with the following use-cases in mind:

• User – I want to see meaningful messages about what went wrong and next steps. I never want to see 250 lines of stack traces, except when accompanied by a "report an error" button.
• Integrator – I want to be notified about all PHP and JavaScript errors and handle then on my own. I may discard the logs, feed them into an LLM, put them in a collective "logs" file, send to a REST API, or do anything else.
• Playground maintainer – I want to see all the error information when and where available. I never want to lose any error message or stack trace to a logger bug, serialization issue, postMessage problem, PHP crash etc.

Here's a list of constraints to consider:

• Every relevant error must be logged exactly once. We can't lose it, we don't want to log it multiple times.
• Platform failures and userspace failures must be distinguishable. For example, WASM runtime crash matters to Playground maintainers, while a PHP process exiting with "undefined function wp_nosuchfunction" matters to Playground users and integrators. They're actionable in different ways (report a core problem vs adjust a line of code and re-run)
• Platform JavaScript errors (Asyncify-related WASM crash), PHP errors (e.g. SQL query failing), and rendered JavaScript errors (e.g. React error in Gutenberg) all matter
• Playground has user-facing apps on playground.wordpress.net, CLI, in VS Code
• Playground exposes npm packages for the browser and CLI
• Playground can run in the same process, in a subprocess, in a worker, in an iframe
• Playground uses service workers on the web
• Playground can spawn an arbitrarily large tree of JavaScript workers and PHP runtimes structured in all ways imaginable
• Structured Exception information, process exit information, and text information matter alike and should be preserved across the process boundary
• Unhandled rejections matter. Asyncify errors, sadly, tend to be unhandled rejections. We try to tie them to a particular Error but some fall through the cracks.
• A PHP exceptions 4 workers deep needs to bubble up all the way to the top-level php.run() call and carry all the contextual information with it. It should be a real JavaScript error, not an event or any other substitute.
• We can never trust PHP to produce untainted, structured JSON information on stdout or stderr. It's always text data with probable warnings etc. We can have a separate file-based pipe for structured message passing.

A few thoughts to maybe make it easier:

• A single, global logging config should be fine, e.g. we always log all errors immediately, or we always propagate them to the parent worker, or we always discard them. There should never be a need to treat one of the workers in a special way error-wise.
• In some ways, this resembles linux, but we don't quite use the same process model with shared memory and filesystem. In other ways, this resembles Sentry where app-level logs preserve context and are sent to a centralized location.

cc @brandonpayton @bgrgicak @draganescu