It occurred to me that, because I have a number of projects that implement their own command loader, that exposing an “Aggregate Command Loader” that could accept multiple command loaders at runtime, perhaps by way of a delegator might be a useful addition - For example, provide a default aggregate command loader via configuration that consumes the current container command loader and expose a public method such as addCommandLoader(SymfonyLoader $loader). Then is becomes easier to bring multiple sources of commands together in a single cli tool.
Alternatively, the aggregate could require an iterable to its constructor such as config.laminas-cli.command-loaders.
get and has inside the aggregate could just iterate over the configured loaders in order of registration… or perhaps in reverse order, meaning that loaders registered later on could override commands configured earlier - this would work nicely with the shipped ContainerLoader that attempts to new configured commands when not present in the container.
This would require shipping a ConfigProvider / Module, but the cli tool could conditionally create a ContainerCommandLoader when there is no AggregateCommandLoader available in the container.
It might also be desirable to alias this AggregateCommandLoader to the Symfony command loader interface making it the intended single source for commands…