Reintroduce erlang-nox with dependencies on new split packages?

Context

I am running some applications that require Erlang/Elixir on a headless VPS.

Previously, erlang-nox was enough to satisfy requirements for such programs. However, recently, erlang-nox was replaced by erlang-core and several split packages.

In replacing erlang-nox just now, I ended up having to additionally manually install at minimum (after some hunting):

• erlang-ssl
• erlang-syntax_tools
• erlang-xmerl
• erlang-parsetools
• erlang-os_mon

Question

Would it make sense to package something similar to the old erlang-nox so that Arch users can conveniently install what they might need without pulling in xorg/java/etc as the main erlang package would pull in?

For example, Debian has an erlang-nox package which depends on split packages: https://salsa.debian.org/erlang-team/packages/erlang/-/blob/master/debian/control?ref_type=heads#L471

Translating that into Arch package names, that would be:

• erlang-base -> erlang-core
• erlang-asn1
• erlang-crypto -> provided by erlang-core
• erlang-diameter
• erlang-edoc
• erlang-eldap
• erlang-eunit
• erlang-ftp
• erlang-inets
• erlang-mnesia
• erlang-odbc
• erlang-os-mon -> erlang-os_mon
• erlang-parsetools
• erlang-public-key -> erlang-public_key
• erlang-runtime-tools -> erlang-runtime_tools
• erlang-snmp
• erlang-ssh
• erlang-ssl
• erlang-syntax-tools -> erlang-syntax_tools
• erlang-tftp
• erlang-tools
• erlang-xmerl

Packages in Arch system or user repos are free to declare only the necessary subset, but for programs not packaged by Arch it would be very convenient to have something filling the same role as the old erlang-nox package.

Perhaps if "erlang-nox" is unusable as a name due to conflicts, then it could be a meta-package or package-group called something like "erlang-common" or "erlang-headless"? I assume it would be more disruptive to rename erlang to "erlang-full", but maybe that's also an option?