Consistency is good, but this patch breaks a different consistency! Specifically, the symbolMaps files count permutations from 0. So permutation 3 in the compile report would be permutation 2 in the symbolMaps files. I think that consistency is more important than that the permutation counting and split point counting use the same numbering. If someone reads about permutation 3 in their compile report, they should be able to safely look at permutation 3 in the symbol information and in any other files the compiler emits.
The easier of the two numberings to change is the permutation numbering. The symbol maps numbering must be coming from some PermutationResult or something. We could trace backward to find out where that number originally comes from, and shift them all to be 1-based. Making the split point numbers 0-based is certainly possible but could touch a lot of code. The biggest issue is that CodeSplitter already uses split point 0, which doesn't really exist, as a convention indicating the initial download. If split point 0 was a real split point, then some other number would have to be used. Lex -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
