getPhase():int -> getPahse():CompilePhase looks like a breaking change. Then, shouldn't nextPhase(CompilePhase) be an operation on the enumeration? Next thing is, hat gotoPhase(int) calls gotoPhase(CompilePhase). If the int taking method is overwritten, but only the CompilePhase taking method is called, then the method changed by the user is not called and his logic is changed. I see this also as incompatible change then. More or less the same goes for ProgressCallBack#call. Well in the later case the possibility is quite low, but it is a possible problematic point.
then a question... why didn't you use a for-each in Java5#addPhaseOperations(CompileUnit)? Well not so important.
What is missing in this patch is making Phases itself deprecated.
Then about adding phases... as long as the numbers are there in parallel, your text is speaking against adding phases, because even if it is an enum, the ordinal number will still change, thus the phase number will change, and the used integer will be of false value. So adding new phases without the disadvantages you mentioned would be possible only after Phases has been completely replaced by CompilePhases.
Then another thing... it doesn't matter how much phases you have, there will always be an operations that does not fit a certain phase by name or that has not really a good place. So instead having phases by functionality we have phases by semantic and stub generation is surely a functionality, as it is not a required phase by the compiler. Also the position where we might want to have the stubs to kick might move, what do we do then? Change CompilePhases? You may have noticed, that each phase already contains a more than one phase operation without going to floats or such things.
Also, what if we in the future use a compiler that will work without stubs and compiles the java code directly then instead? Then these two phases would be strange looking at last.
So all in all I vote against this change to happen for 1.6. It is a breaking change, and it doesn't matter how much you try to duplicate the methods, just because they are there, does not mean they will be called like before, and methods with the wrong return type are surely a problem.
No I think if this change should be done, then as a breaking change from the beginning and as part of other compiler changes that will break things. I tend to say this will not happen before 2.0, so it will take several months before this can happen, but at last we would have only one release with lots of breaking changes instead of several releases where the ABI in each of them breaks a little here and there...
ah yes, a side note... in pure groovy code without the usage of types, this change could have been done without being a breaking change 
Sub-task
Reopened
Major
getPhase():int -> getPahse():CompilePhase looks like a breaking change. Then, shouldn't nextPhase(CompilePhase) be an operation on the enumeration? Next thing is, hat gotoPhase(int) calls gotoPhase(CompilePhase). If the int taking method is overwritten, but only the CompilePhase taking method is called, then the method changed by the user is not called and his logic is changed. I see this also as incompatible change then. More or less the same goes for ProgressCallBack#call. Well in the later case the possibility is quite low, but it is a possible problematic point.
then a question... why didn't you use a for-each in Java5#addPhaseOperations(CompileUnit)? Well not so important.
What is missing in this patch is making Phases itself deprecated.
Then about adding phases... as long as the numbers are there in parallel, your text is speaking against adding phases, because even if it is an enum, the ordinal number will still change, thus the phase number will change, and the used integer will be of false value. So adding new phases without the disadvantages you mentioned would be possible only after Phases has been completely replaced by CompilePhases.
Then another thing... it doesn't matter how much phases you have, there will always be an operations that does not fit a certain phase by name or that has not really a good place. So instead having phases by functionality we have phases by semantic and stub generation is surely a functionality, as it is not a required phase by the compiler. Also the position where we might want to have the stubs to kick might move, what do we do then? Change CompilePhases? You may have noticed, that each phase already contains a more than one phase operation without going to floats or such things.
Also, what if we in the future use a compiler that will work without stubs and compiles the java code directly then instead? Then these two phases would be strange looking at last.
So all in all I vote against this change to happen for 1.6. It is a breaking change, and it doesn't matter how much you try to duplicate the methods, just because they are there, does not mean they will be called like before, and methods with the wrong return type are surely a problem.
No I think if this change should be done, then as a breaking change from the beginning and as part of other compiler changes that will break things. I tend to say this will not happen before 2.0, so it will take several months before this can happen, but at last we would have only one release with lots of breaking changes instead of several releases where the ABI in each of them breaks a little here and there...
ah yes, a side note... in pure groovy code without the usage of types, this change could have been done without being a breaking change