Hi,
Since there was no contact given and the GSoC2009 wiki page said the mailing 
list is the place to ask about it, I decided to put my questions here.

I'm a bit curious about the project idea. I'm thinking, that one could use 
module[1] as an inspiration. And to create a "emodule" system, some what 
analog to the ebuilds portage uses. These emodules would be installed (and 
removed automatically) by packages that provide/utilize eselect functionality.
I'm thinking about using basically the same structure as module[1], that is:

  $ eselect use python/2.5/2.5.7-r7
  Selecting python/2.5/2.5.7-r7...done
  $ eselect show python
       python/2.5
    SU python/2.5/2.5.7-r7
       python/2.5/2.5.7-r8
       python/3.0
       python/3.0/3.0-r1
  $ eselect use python/3.0
  Selecting python/3.0/3.0-r1 (latest version for python/3.0)...done
  $ eselect show python
       python/2.5
    S  python/2.5/2.5.7-r7
       python/2.5/2.5.7-r8
       python/3.0
     U python/3.0/3.0-r1

 listing 1: an example says more than a picture expressed in words ;)
            note: this is a fictional example, since we can't have
            two installed versions of the same slot via portage.

Where the "first level" (read: "python/") is the emodule name.
The second (read "2.5" and "3.0") is the equivalent to slots in ebuilds 
(possibly required to match, but that's a later design choice - one could 
imagine that app/foo:1 installs /usr/bin/foo-static and /usr/bin/foo-dynamic  
and a /usr/bin/foo symlink to one of the, here eselect could control that 
symlink).
The third level (read: "the final version numbers") is the "absolute emodule 
name".
Selecting by first or second level should select the latest version available.
In the example above "eselect use python" would select python/3.0/3.0-r1. 
Where as "eselect use python/2.5" would select python/2.5/2.5.7-r8.

eselect would have 2 modes, system and user (user being default). The 
difference could be that system ("S") would control the system default - i.e. 
what version /usr/bin/python is, where as user ("U") would control "env 
python" (i.e. what python you get when just typing "python" in the shell).
The user part could be implemented by use of $SOME_EMODULE_DIR/module/x/y/bin 
where a symlink with the generic name links to the correct version, or 
possibly is the real app. (in the python example 
$SOME_EMODULE_DIR/module/3.0/3.0-r1/bin/python would link to 
/usr/bin/python3.0).
<off-topic>
afaik one should actually prefer "/usr/bin/env interprenter" over an absolute 
path for the shebang in shell scripts, with the exception of /bin/sh or 
/bin/bash and when one "knows" that the absolute path _really is_ the one we 
want/need. (eg /usr/bin/python3.0 for version 3) - ie prepending "dummy-bin/" 
folders in PATH "selects" which python elf to use.
</off-topic>

And just like module[1] eselect would have the distinction of use for this 
session (cf. "module add" or "module load") and for future sessions (cf. 
"module initadd"). The later might require more extensive work (i.e. ensure 
some part of eselect is run when starting shells so paths, etc, can be set - 
though, this might create an noticeable overhead for starting shells).


I regularly come across the module found on the Solaris machines at LiU and 
think the general concept of module is nice/handy.
I think that one could make it more user friendly by for instance flagging 
some of the emodules as system (or derive that from emodule scripts, e.g. 
.opengl selection would be marked system since admin rights is needed to do 
the actual 'selection')
For regular users the system modules would be hidden, reducing the module list 
somewhat.
 Further more, by trying to make the use as intuitively as possible (eg not 
the confusing "module add" and "module load", which do the same, but instead 
name it "eselect use" or "emodule use"). I think simply using sane naming 
would make it more user friendly.
 But I think there's a intrinsic problem that usability will decrease as more 
modules exist to choose from (all the user sees is a 500 line list of text and 
numbers instead of 500 choices). For the most user friendliness increase would 
be to create a simple GUI which could present the choices in a better way 
(note: the GUI would be a complementary aid, the CLI would be the backend 
driving it all).

I can't quite make any sense of what this line in the idea description means: 
"There's eclectic in Exherbo so probably should just switch to that. In that 
case not enough work here for GSoC.".
- Maybe it's just my english that's failing or there's words missing there.

[1] <http://modules.sf.net> the module mentioned in the wiki proposal

Best Regards
Fredrik

P.S. perhaps a short description of me would be fun:
My name's Fredrik Klasson (aka scientica or mojibake), after a soft start to 
university studies with a year of japanese studies I revealed my true colors 
and started studying computer science at Linköpings Universtitet (Sweden). I'm 
currently in my 3rd year with the aim at a Master of Science (2 yrs) with a 
major in CS (due to the Bologna process and transitional regulations I'm not 
sure exactly what the formal title will be in the end, but it's lot's of fun 
CS - the important part is what I learn not what the business-card says :)
I came across the "Universal select tool" GSoC idea via the wiki linked from 
an Gentoo Linux News news feed, and thought it was an interesting idea worth 
thinking about.
-- 
After all, if you are in school to study computer science, then a professor
saying "use this proprietary software to learn computer science" is the
same as English professor handing you a copy of Shakespeare and saying
"use this book to learn Shakespeare without opening the book itself."
  -- Bradley Kuhn