Stratification of GNU Guix into Independent Channels

[jgart]

Hi Guixers,

I wanted to ask you what are your thoughts on this idea. This is a thought 
experiment at this stage.

Should GNU Guix be a small core of packages (and services?)?

For example, GNU Guix would be a core channel containing the reduced binary 
seed bootstrap and a few other core packages to bootstrap the system. That's 
it. Users subscribe to this channel to get started.

Users could then decide what channels they'd like to subscribe to/opt in to by 
adding any of the following channels as they please:

python-channel
rust-channel
lisp-channel
node-channel
ocaml-channel
clojure-channel
chicken-channel
go-channel
haskell-channel
erlang-channel
elixir channel (maybe elixir and erlang are together in one channel)
elm-channel
gaming-channel
texlive-channel
ruby-channel
linux-channel (kernel)
java-channel
emacs-channel
vim-channel
perl-channel
php-channel
julia-channel
r-channel
dlang-channel
purescript-channel
mozilla-channel
chromium-channel
browsers-channel
coq-channel
agda-channel
idris-channel
kde-channel
gnome-channel
xfce-channel
enlightenment-channel
pantheon-channel
scheme-channel
etc...

The above channels would still be maintained under the auspices of GNU.

What do you think would be the pros and cons of the stratified approach versus 
the monorepo approach that we currently have?

This is mostly a thought experiment as implementing something like this, I 
imagine, would be quite ambitious and radically different from the approach we 
are currently following. 

I'm curious to know what the community thinks about the stratified approach. 
I'm also curious to learn more about the history of why we chose the monorepo 
approach. Are there any references that I can read for the latter?

Here are some pros I can foresee with the stratified approach.

Pros
=========

GNU Guix proper would be a solid core of packages that is very easy to 
maintain. This would greatly reduce the maintenance burden since maintaining a 
world of rust, golang, or python packages is opt in by those who want to do 
that particular work.

Users can opt out of certain channels. For example, there might be some users 
that want absolutely no rust or some other language or ecosystem of packages 
from being downloaded on their machine for whatever reason. Same goes for any 
other languages.

Would being subscribed to just the hypothetical small core channel in this 
proposal increase download/installation speeds given the availability of 
substitutes?

WDYT