Description
The symfony/intl package provides 2 independent sets of features:

• polyfills for various ext-intl classes exposing ICU features (IntlDateFormatter, IntlNumberFormatter, Collator and Locale)
• public APIs exposing some CLDR data that is not available through ext-intl. That's the \Symfony\Component\Intl\Intl class in older Symfony versions, and its replacements in newer versions (\Symfony\Component\Intl\{Currencies,Locales,Locale,Languages,Countries,Scripts,Timezones})

When we created the symfony polyfills (many years later), we created a symfony/polyfill-intl-icu, which is semantically meant to provide the first half, but is actually implemented by requiring symfony/intl. This has several effects:

• it does not make it clear what the intended usage is (in the modern way, packages needing only polyfills for ICU classes should depend on symfony/polyfill-intl-icu)
• packages requiring symfony/polyfill-intl-icu actually receive the full symfony/intl package, which is by far the biggest contributor to the size of vendors among Symfony components (and bigger than many packages in the ecosystem) due to the size of the CLDR data, which is not needed for their use case.
• polyfills are using a very specific architecture (all the implementation goes in an internal abstract class used as parent), which is very common in symfony/polyfills but can be confusing when finding it in symfony/symfony (see [Intl] IntlDateFormatter is abstract, yet it promotes instantiation #37756 for instance, which is caused by such confusion)
• if you use the replace trick to remove unnecessary polyfills because your project has a requirement on ext-intl, you will still get the polyfill implementation in your vendors (which might confuse the IDE due to double class definitions)

Proposal
My proposal is to actually move the implementation of ICU polyfills to symfony/polyfill-intl-icu directly (the only change needed would be the namespace used for internal classes), and then change the order of the dependency. symfony/polyfill-intl-icu would be standalone, and symfony/intl would require symfony/polyfill-intl-icu (with the new version containing the polyfill as lowest bound).
This would give clear responsibilities to both packages, one providing the polyfill and the other one providing extra features.

The only impact would be on projects requiring symfony/polyfill-intl-icu and actually using the symfony/intl APIs without noticing they don't define a requirement for them, as symfony/intl might not be installed anymore. But the symfony/polyfill-intl-icu package does not document that these APIs become available due to the implementation details.