Thanks for surfacing this again, Mads. As you mention, the linked thread does discuss some potential solutions to getting the ICU dependency size down (externalizing the ICU data so it can be thinned and not duplicated across the Android architectures, or adding a FoundationAndroidICU substitute library that uses JNI upcalls for its i18n needs in order to share the system ICU data, etc.) But it isn't something that is going to be solved in the short term.
You are right that this is hampering adoption: it is the number one reason our users cite for sticking with Skip's "Lite" mode (where a transpiled Hello World apk is 17MB) rather than the "Fuse" mode that uses the Swift SDK for Android (where a compiled Hello World apk is 124MB). Solving this is a high priority for us.
But in the short term, eliminating unnecessary dependencies on FoundationInternationalization would be a great help. I understand why this causes a source-breaking change (and thus forces burning a major release under the policy of many projects):
#if canImport(FoundationEssentials)
import FoundationEssentials
#else
import Foundation
#endif
… however, I wonder if perhaps this might pass muster:
#if os(Android) // and os(WhateverElse), like MUSL…
import FoundationEssentials
#else
import Foundation
#endif
It might require the call site to add an extra import sometimes, but given that this would only be for platforms that weren't (officially) supported until now, maybe this is a change that wouldn't need to be considered "source breaking"? After all, adding Android support sometimes requires adding extra imports anyway (see Exploring the Swift SDK for Android | Swift.org), so adding Android platform support to a package isn't expected to always just work "out of the box".