Let's say I have a road with casings as follows:
This works as expected. Now, let's add another road as follows:
This draws the trunk roads on top of the secondary roads, also as expected. So far so good. But let's suppose we have lots of roads and want the more major roads always on top. So we have the following code:
This time, it is the secondary roads that are drawn on top despite having a lower z-index (10 < 20: FAIL). This is inconsistent with previous example (0 < 10: CORRECT). So, let's take it a bit further. If I make the Z-indexes of the secondary roads 20 & 21 and raise the trunk roads z-indexes to 30 & 31, then we are back to correct rendering order (trunk on top). Go one step further and make secondary roads 30 & 31 and trunk 40 and 41 and we return to a FAIL. Again, testing with extreme z-indexes of 10,11 vs 100,101 fails but 20,1 vs 200,201 renders correctly.
So, in conclusion, z-index works sometimes and fails other times and is not solely dependent on the relative size of the indexes. The documentation does not specify any limit and I don't know if that is what I am experiencing, though why values in the hundres do sometimes work, suggests that this is not the case. If there is a low limit on z-indexes, it is very handy to be able to use large values (>>0-9) because you can then use the units to order parts of a feature (e.g. roads with casings) and the tens or hundreds to order types of feature (so in my use-case tertiary roads are 10-19, secondary 20-29, primary 30-39 and so on).
Windows 64, Geoserver WAR running in Tomcat 7