Update #1 to original proposal.

As I started working on implementation I realised that ebuild name mangling is not the best way to go. It would require a good amount of small modifications to portage.py and other tools and will produce many special cases that would have to be dealt with. Most problematically would there be a need to change anything, this whole naming scheme will have to be redesigned as well as a lot of code rewritten.

I came up with a better approach: leave names as they are now and just describe package states in a separate file, one per package. Lets call this file Status, let it reside next to ebuilds and Changelog in the category/package directory. File contains entries that are meant to describe package state - one per line.
Ebuild states follow the model described in original proposal, however in a more generic form. The information stored in the file has the following form: 

#file format:
#${PVR}	  confirmed_flag  approved_flag
2.1       no              yes
This will give a total of 16 combinations. However considering degeneracy of the ebuild stability states there will only be 7 distinct stability levels (ordered less -> more "secure"):
eStatusList=["unstable","new","confirmed","appr-new","core-new","approved","core"]

For the detailed description of these status/stability levels please see original proposal (for brief excerpt you can take a look at the summary section).
Please also take a look at examples (heavily commented, well in fact just consisting of comments at this point :)) Status.skel and the (very early stage) code estatus.py.

Some general discussion:

The correspondance of pair of flags to the stability level is set via the following:

  1. unstable in any position marks ebuild as "unstable"
  2. core in approved_flag position marks package as having "core" status; ebuild is supposed not to have core in confirmed_falg position.
  3. the rest is maps accordingly to the following table (order is essential):
    ('no','no'): "new"
    ("yes","no"): "confirmed"
    ("no","yes"): "appr-new"
    ("yes","yes"): "approved"
    ("no","core"): "core-new"
    ("yes","core"): "core"
As usually code is the most authorative source at early stages :).

If you read the original proposal, the following levels may catch your eye as not being much represented before: appr-new, core-new. They are supposed to be used for a new packages or revisions submitted by core developers (appr-new) and for new core packages (or revisions of). I assigned them stability level in between confirmed and approved: effectively these packages has been approved since core devs took care of them. Additionally core-dev approval is considered to have more weight then general usr notes.
I should note, that even though these levels are present in the code it is not absolutely necessary to enforce them. Setting StabilityLevel=appr-new will effectively treat them on par with approved packages.

The previous example can serve as just one illustration of a flexibility of such approach, note that a lot of tuning of the model can be done without the need to change any code! Even better, code changes are trivial for even complex model adjustments and mostly contained to few mapping structures.

What about the code itself?
It seems to be feasible to provide most of the functionality in a separate module (estates.py). portage.py will require only minor modifications to extend masking functionality.

Is this all?
Hardly, rather this is an important first step. Full proposal has a goal to allow all interested users to contribute/test and by other means take care of the ebuilds thay will choose (and will allow us to spend more time on other interesting topics ;)).
However this part is usefull on its own, as it allows to create a stable distribution within the same tree thus alleviating problems of syncing between various development trees.