On Sunday 06 December 2009 11:48:13 Ulrich Mueller wrote:
> >        Depending on the exact wording and exceptions this can be
> >        made equivalent to 5.3 below.
>
> Right, that's the intention of it.

The intention is to make the spec for a new EAPI unnecessarily complex, just 
to avoid changing an existing implementation?

> We should also consider including this in EAPI 0 retroactively

Doing things like that defeats the purpose of EAPI.

>   2007-07-28  Portage 2.1.3 is released, preserving mtimes when
>               merging (if release candidates are counted, then the
>               date is even earlier [2]).

This was long after EAPI was invented, so it should have gone in with an EAPI 
bump.

>   2008-05-08  PMS allows that file modification times are discarded. [3]

That commit changed the wording from "Other file attributes may be discarded" 
to "Other file attributes, including modification time, may be discarded".  
Modification time was already included in the phrase "other file attributes", 
all the change did was to clarify it.

Also note that just because something isn't mentioned in PMS doesn't mean it's 
OK to go off and do whatever you feel like, without regard for compatibility, 
especially if it's a long-standing, well-defined behaviour like "reset mtimes 
to the current time".  People are expected to use common-sense when reading 
it (since we don't have enough man-power to make it completely airtight), not 
deliberately misinterpret it to support their own agenda (last part not 
directed at you, but that sort of behaviour has happened in the past).