Except using global state and hardcoding, I don't see how one could make each tracing decorator know about the profiler - they're decoupled.

OK, here is a way: make the added $enabled properties bool|Closure():bool, then make all tracing decorators call the closure everytime there's a need to fetch the current state. Then generate this closure using DI and some bridge class between the profiler's state and the bool that we need.

Let's try the current simpler approach first and improve later, if the need arises.

The Closure would be $profiler->isEnabled(...). This could create a circular reference.

The Closure would be $profiler->isEnabled(...). This could create a circular reference.

Basically yes, but I'd do it in a more subtle way: I'd add a intermediary closure who would get the profiler using a scoped container, and this container would reference the profiler using IGNORE_ON_UNINITIALIZED_REFERENCE, so that the profiler is not instantiated on this side of the relation.

PR updated with the closure I described in my previous comment: I figured out it was actually simpler this way, because it then doesn't need patching data collectors anymore.

@nicolas-grekas according to #60037 (comment)

In devland code (external bundles or app « tracers »)

What are the changes required to mimic this?
only inject such new service and check the state prior to code exec? If so cant this be autowired in some way or not?

Is it worth an entry in the doc as well ? (Perhaps near data collector section as most likely to be related)

Autowiring that should be possible with some named alias. I'm not going to be able to update this PR soon but it could be merged and followed up by the alias one.
Doc indeed!

Feel free to ping me for doc part :)

Thank you @nicolas-grekas.