It appears the change was made in response to bug 1512, which was believed at
the time to be editorial only. The issue remains open.

In raising this comment I asked why the change had been made: it appears it was
made in response to a comment from Joanne Tong (bug 1512) which was wrongly
classified as editorial. I didn't actually express a view about whether the
change was desirable.

I would now argue that the previous specification is better: the value returned
by max() and min() should be one of the values in the input sequence after
atomization and conversion of untypedAtomic values, but before type promotion.
The main reason for this is that "promotion" from decimal to double can lose
precision. For example, if @default is the untypedAtomic value "0.0", the result
of max((1.123456789123456789123456789, @default)) should be the value supplied
in the argument, not the result of rounding this value to the nearest double.

I spoke with our developers and they think the status quo is the best way to 
use existing language aggregators since they normally get invoked after 
atomization and type promotion. With the proposed change, you would have to 
either preserve both values in that case and their relationship which would 
make the aggregators very costly to use or write a completely new aggregator 
which is not a good idea either.

Therefore, we think that the changes done in 1512 should stay.

I've been thinking more about this, and beyond my original reasons given in
comment #2, I think there are further reasons why the original spec is better.
For example, consider max(($DEC, $FLT, $DBL)) where $DEC > $FLT and $DEC < $DBL.
Can I get the right result in a pipelined implementation? According to the spec,
all the values need to be converted to doubles before any comparisons are done.
If we try to pipeline this, there's a danger of getting the wrong answer. If I
start by comparing ($DEC, $FLT) by converting $DEC to float, I risk hitting a
boundary case where the result of converting $DEC to float is greater than $DBL
even though $DEC itself is less than $DBL (this includes the case where
float($DBL) is +INF). 

I can avoid these errors by retaining $DEC (the original value) as the value of
"max so far", and at the same time keeping track of the "highest type
enountered", and at the end converting the "max so far" to the "highest type
encountered". But it's extra work, and all it achieves is to give a poorer
result (one that loses precision). I think it's better for the user, and easier
for the implementor, if the result is always one of the numeric values actually
present in the sequence: "max so far" without further conversion.

Michael Rys' argument seems to be based on the ability to reuse implementations
that exist in other environments. It seems to me unlikely that such
implementations would accept streamed input in the right form, and therefore
unlikely that a high-performance XQuery implementation would choose to use them.
But perhaps he is relying on the ability of static analysis to determine the
target type in advance. Unfortunately we don't all have that luxury.  

On today's telephone conference the joint meeting of the XSLT and XQuery 
working group decided to keep the status quo and return the selected value 
with the type it has received during the promotion.

Since you were present and expressed acceptance of the decision, we are 
closing this bug as won't fix.