Do you know that /etc/init.d scripts deprecated numeric ordering and are 
switching to relative one?

I had not heard that. (Reference? Google turns up nothing.) Nonetheless the
justification listed in the wiki still applies.

http://initscripts-ng.alioth.debian.org/soc2006-bootsystem/deliverable1/debianboot_d1.pdf

Interesting, but a quite different situation with little bearing on NB.

Dafe will be interested in this too, as he had to reorder Windows menu for M9.
And was not lucky about that, surprisingly...

Great! I spent many evenings with relative ordering and proposed change will
make our developer life (and life of our customers) much easier, I fully support
proposed solution. Thanks for this...

*** Issue 24776 has been marked as a duplicate of this issue. ***

A thing which is still not fully clear to me is whether this is proposing an 
incompatible change or not. If it is, then I'd like to remove the FAST from 
API_REVIEW_FAST, if there was such keyword. Anyway, I'd like to see a 
discussion about possible options before doing an incompatible change.

I don't expect any incompatibilities. As detailed in the wiki, relative ordering
attributes would continue to function, after logging warnings.

It's not up for API review yet because I am still developing it. But you can see
the plans on the wiki.

I would like to submit this change for API review, targeted for inclusion in
M10. Everything you need to know is in the wiki. I am continuing to work on
implementation (mainly usages of the new API) but the API itself, including
usage in DataFolder, should be ready for review. I expect changes to be
compatible - while I will upgrade all modules in the standard IDE, unmodified
third-party modules should still be able to insert files in relative positions
(with warnings printed to the log).

I support a module unchanged between NB55 and NB60 (thanks to a little
reflection). One problem was the position of a Tools menu item. Discovering that
position was determined through a tsort algorithm actually made is simple to set
it up so the same layer file worked with both NB versions. The wiki seems to
indicate that good practice, when changes are made, is to keep existing numbers
as possible. There's a question in here somewhere...

How difficult do you think it will be moving from release to release with the
absolute verses relative schemes?

To err's question:

If the immediate context of your menu item does not change between releases,
then relative ordering attributes are OK: you can use the same pair of attrs for
both releases. The problem arises when the nearby menu items do change. In some
cases you can overspecify your order in such a way that your item will still
show up in the right place in both releases. (If the menu is totally rearranged
this might not be possible, though this is rarer.) This can be pretty
cumbersome, however.

Using numeric positioning, you would just choose an appropriate position in the
earlier release and then check up on it in the newer release. It is possible
your menu item will have "drifted" a bit, though catastrophically wrong
positions are much less likely than when using relative attrs. You are correct
that it is desirable for maintainers of the IDE/platform/whatever to not make
gratuitous changes to positions of existing menu items between releases.

As mentioned in the wiki, I have a script which I plan to use to replace all
relative attrs with numeric positions in the full IDE (i.e. including visualweb,
uml, ...). It simply assigns positions 100, 200, 300, ... to each file/subfolder
in the desired order. This should be enough to get us started, though probably
for 6.0 we will want to hand-tune the positions for important areas like the
menu bar and list of templates, so that separators are placed e.g. at multiples
of 1000 and perhaps named according to their position ("sep2000.instance").

Created attachment 43839 [details]
Log of relative -> position conversion

Created attachment 43840 [details]
Commit log

Implemented in trunk. Minor tasks remain, as detailed in wiki.