Posted By: sdellysse* Separation of libraries from /Programs to /Libraries

If that means what I think it does, I don't think that's plausible. There isn't the distinction necessary between the two (curl: program, or library?), so it would just be an arbitrary split, which sort of defeats the purpose. On the other hand if you just want to access the libraries through there, make a symlink to /S/L/L.

Posted By: sdellysse* Separate out the system services to a /Services directory

I'm not sure what this one is getting at either. Tasks already have their own location (/S/L/Tasks) and are stored with their associated program (under Resources/Tasks). If you mean something else by system service... then we're back to arbitrary distinctions again. Might as well throw them into sbin and be done with it.

Posted By: sdellysse* Have some kind of metadata for the packaging. Maybe a .goboMetaData file in the version directory of the package. This file would have the package dependencies, a thorough description, and a list of the commands exported from the package. I'm think of a javadoc-like system as I am writing this.

There is already package metadata for dependencies and descriptions in the Resources/ directory, in the logically-named files within there. You can get a list of commands exported just with `ls` on the program's bin directory (or, extract it from the FileHash data if you're wedded to the metadata concept). The data's already there, so including it in another file (and a hidden one too) wouldn't serve much purpose. Javadoc really wouldn't be suitable for the task in any case.

In general, we're not in favour of a) arbitrary distinctions between things or b) unnecessary duplication of data, so if I've understood your points correctly, none of the first three are candidates to happen.

Posted By: sdellysseAlso, something further down the line, a cascading system, using a form of UnionFS
for example:
$userPrefix/Programs and /Programs unions simply to $userPrefix/Programs
and etc, for each of the managed directories in the root.

This one, on the other hand, has been discussed before and I think there's a reasonable possibility that it will occur, after the /System/Index changes make it into the mainline. (short summary: /S/Index will use a virtual filesystem to provide a view of installed programs and do what is now done by symlinks in the /S/L tree). At least, it should be possible at that point.

It is also possible to run Rootless inside Gobo if you want to have individual users compile their own programs and store them in ~.