I always thought about defaults as "most people would like these" rather than "removing these can break your system".
In particular, switching to openssl instead of mbedtls is kinda probably because of libustream-mbedtls being a default.
Defaults is a build thing, not a packaging thing. Defaults simply give you a starting point that says "use these and you'll get a running OpenWrt". They should not have any impact on dependencies or package interaction.
It might be a good time during all of this other thrashing to fix the dependencies on everything, take full advantage of the apk switchover and let it do its job as designed.
One of my current thoughts is to also get rid of the ABI-versioned package names, and just use apk constraints to manage the dependencies properly (my archeological digging strongly suggests that the ABI-names are an artifact of opkg's lack of functionality in this regard).
And yet if you check dependencies on kernel (opkg whatdepends or apk info --rdepends), you see many dependencies.
I don't see how uci is different than any other package, you shouldn't be able to just say opkg remove uci or apk del uci and have it actually remove uci and not complain... That's the whole point of having a package manager, to protect yourself from such gaffs, and the only way to do that is to properly declare all dependencies.
Oh, should have added an example of something with properly defined dependencies:
$ apk del --simulate kernel
World updated, but the following packages are not removed due to:
kernel: kmod-r8169 kmod-igb kmod-dwmac-intel kmod-amd-xgbe kmod-igc kmod-e1000e kmod-ixgbe kmod-tg3 kmod-bnx2 luci-app-sqm kmod-nft-offload nftables dnsmasq-full ppp ppp-mod-pppoe kmod-e1000
conntrack kmod-button-hotplug kmod-amazon-ena kmod-fs-vfat ss kmod-forcedeth
I haven't checked if apk can model ABI dependencies without that yet, but massive packaging changes are better delayed until opkg is really dead (when 23.05.x becomes EOL, assuming that apk still makes it into 24.10.x, which I wouldn't take for granted, yet), as these would make backporting much harder.
Would you still be able to install multiple ABI versions of a library side-by-side, or would you have to upgrade all packages that depend on that library at the same time you upgrade the ABI version of the library?
why this new change, when something is good and stable, then someone comes and refactor to use apk instead of opkg, what is the reason? just playing? generating more work?