Of course =<category>/<name>-<version> might have been replaced by %{EQNAMEVERSION}.

Still not really, because it is not yet possible to store properties in runtime variables. What you can do is to print all those packages for which the best version (of a slot) is in an overlay but the package is not only in one overlay:

This is hard to read but actually not deep. It does the following for each version: At the beginning of each slot ("{slotfirst}...{}") the runtime variable v is cleared; if the version is not from an overlay, it is stored in the runtime variable v. Finally, for the highest version of each slot ("{slotlast}...{}"), if the version differs from the runtime variable v and is from an overlay, it is output. The argument --overlay and the condition in the format outputs only versions which have at least one version in the stable tree and some in some overlay.
One modification: If you want to see only versions which have an higher version in an overlay than a version of the same slot in the tree, you can replace %{NAMEVERSION} by {$v}%{NAMEVERSION}{}, i.e. the output happens only if the runtime variable v was really set in the current slot (by a version in the tree).

my first test shows that the provided command does not take masking of packages in account.
is it possible to constrain that list to only output packages that are not masked ?
by the way: is there a live eix ebuild somewhere?

my first test shows that the provided command does not take masking of packages in account.
is it possible to constrain that list to only output packages that are not masked ?

The following code remembers in the runtime variable v the latest unmasked version if it is from the tree or from and overlay (and different from the previously remembered version); in the runtime variable o it is remembered whether the latter occured last. If this is the case when the last version in the slot is reached, this last version is output.

my first test shows that the provided command does not take masking of packages in account.
is it possible to constrain that list to only output packages that are not masked ?

The following code remembers in the runtime variable v the latest unmasked version if it is from the tree or from and overlay (and different from the previously remembered version); in the runtime variable o it is remembered whether the latter occured last. If this is the case when the last version in the slot is reached, this last version is output.

Edit: In p it is remembered whether there was already an output for that package so that the newline is output only in that case.

i'll comment on that later, something still seems to be wrong.

today i ran `eix-test-obsolete -d` and got some redundant entries for /etc/portage/package.keywords. one entry was not listed, "dev-util/gclient **", whereas it is neither installed nor available (i removed the according layman overlay).
is this a minor regression ? eix-0.18.0.

i would like to be able to keep the following cases apart:
[0]
[0=>1]
[1=>0] (not covered in the example)
[1] (not covered in the example)

is this possible with eix ? or is this again a case where dep calculation would be necessary ?
it that is possible it would let me first upgrade the packages that do not need attention ([0],[1]).
upgrade those that were bumped by an other overlay maintainer ([0=1]).
then i could take a look at those that need to be upgraded in the overlay i maintain ([1=>0]).
and

What this does is the following: The first part of MY first checks whether a version of the same slot is installed from an overlay (to this end, the runtime variable instoverlay is unset, the slot is remembered in the runtime variable currslot and then all installed versions are checked whether their slot matches currslot and whether they are installed from an overlay - if yes, instoverlay is set). Now the tests {$instoverlay}{overlaynum}...{}{} succeed both if and only if the package was installed from an overlay and also the new version is from an overlay, i.e. this test corresponds to the case [1=>1]; you get the case [0=>0] by modifying these tests to {!$instoverlay}{!overlaynum}...{}{}, and similarly for [0=>1] or [1=>0] by negating only the first or second test, respectively.

i tried that and its variations in a situation where i have [0=>0], [1=>1] and [1=>0] upgrades. those worked correctly. i am sure [0=>1] works too.
if i understand the command correctly, [1=>2] and [2=>1] have the same effect as [0=>1], right ?
eix was from svn, revision 945.
thanks for the efforts.

No. svn.gentooexperimental.org is still down (maybe not, but nobody knows its IP). So currently the only way for releasing are the new tarballs at BerliOS. If the svn.gentooexperimental.org problem remains, maybe development will switch to the git service of BerliOS. However, except for urgent bugfixes, development will probably be quiet for some time anyway.