Better (or configurable) order of built-in transpilation vs custom transforms vs CSS modules

It seems that all current transpilation steps happen before any of the custom transforms, but the renaming of idents from CSS modules happening after custom transforms.

I don't know how viable it is, but the way I'd expect it to work:

1. Entry custom transforms.
2. Built-in transpilation, CSS Modules idents.
3. Exit custom transforms.

This way it would be possible to adjust things both before the built-in transpilation, and after CSS Modules.

Use cases:

1. Using a custom env() visitor to replace it with some value which is then statically transpiled. Example: doing something like color-mix(in srgb, env(--my-color), transparent). Right now this will not transpile the color-mix as it will be done before the custom transforms, even though we could expand the env() into a static color.

2. Adjusting the ident names for CSS Modules. This could allow to work around things like https://github.com/parcel-bundler/lightningcss/issues/315.

If it is not possible to achieve with the custom setup, I wonder what could be the alternatives?

The issue names built-in transpilation, custom transforms, and CSS Modules, but no files, tests, or entry points. Start by tracing the transform pipeline and existing custom-transform behavior; done means determining whether configurable entry and exit ordering is viable or documenting an alternative.