The main issue here is that UnitSystem is an enum. In #60095, the container.excluded tag was added to all enums, so the ResolveFactoryClassPass no longer resolves the class:

Based on the discussion there, this was intentional, so I'm not sure it qualifies as a bug, even though it is technically a BC break.

It makes sense that this does not work anymore if it has explicitly been removed. But I'd expect that minor upgrades do not introduce these kind of breaking changes?

No need to support this, it'd be broken design :) (https://github.com/symfony/symfony/pull/60095/files#r2021037158)

so it's expected yes.

It's indeed removed but

1. No clue why it was decided to introduce a breaking change between minor versions
2. Why it was decided that "it'd be broken by design"
3. Why this breaking change is not mentioned in the docs

Anyway, worked my way around this by referencing the FQCN instead of null on enum factory methods

As a workaround you can disable autoconfiguration for that definition:

    App\Infrastructure\ValueObject\Measurement\UnitSystem:
        autoconfigure: false
        factory: [ null, from ]
        arguments: ['@=app_config("appearance.unit_system")']

This is how it works by design indeed. I get the BC aspect of this. Changing the behavior of the app is something that's inherent to autoconfiguration. Of course, we're careful not to break anything as much as possible, but I see little alternatives here.

We could find a way to track explicitly-defined services and never auto-exclude them. But that introduces an exception to the rules of autoconfiguration so this might be hard to justify on the long run.

We might also make a special case for enums only, where the autoconfiguration rule is replaced by some similar logic in the FileLoader that does the auto-discovery.

Dunno if any of these options make sense.

I'd be tempted to close as "won't fix" unless we gather more feedback on the topic. (who else is using an enum class as a service? please let us know if this is common enough practive.)

For me this issue can be closed, the autoconfigure: false approach is a valid alternative

My use case for using enums as a service is a self-hosted app running in a docker container. Users can configure this app by means of several yaml files. A lot of the configurable options are a pre-defined list of strings, hence the usage of enums.
I then inject the configured values (enums) in any service where I need them

I see the issue is already closed. But to give some insight in this, we apply a string enum as a service (with the same factory pattern as described above) as a better alternative to injecting a raw string value. That enum also has a few convenience methods so we don't have to do string comparison everywhere.