You are right Kathey, that's a typo on my end. However, since we will probably change things a bit regarding the alternative ports, that patch will stay on hold.
So, the cleaner implementation would imply having a getNextAvailablePort() method in TestConfiguration that would replace our getAlternativePort().
I think that ideally we'd even only allow for the base port to be set and then every other port would build on that by offsetting from the base port. Each time we'd invoke getNextAvailablePort(), we would get an usable port for our a server. Do note that the base port remains fixed throughout the suite run; it is just alternative ports (replication ports, jmx, actual alternative ports that some tests like ServerPropertiesTest require) that would build on upon the base port.
We would have no real offset, the alternative ports would be assigned on the go with lastAvailablePort+1.
Also, Kathey suggested we would create a constant under TestConfiguration named MAX_PORTS_USED, which would tell us the maximum number of alternative ports that can be assigned. This constant would then be used in getNextAvailablePort() in an assert - if the port being requested is over the limit of ports that can be used, it would mean that a new test that uses an alternative port had been added and so the developer would have to update the constant and the wiki page. (This is an attempt to make sure that the wiki page on concurrent test runs is always up-to-date, and that people running concurrent runs always know how many ports they should leave between runs)
To finalize, with this idea, the concept of alternative port is lost. Or better said, it merges with the concept of JMX and replication ports since those would also be obtained through the getNextAvailablePort().
It might be too restrictive to only allow the base port to be set, but I think we would be able to keep it simple this way. If we allow JMX, or replication (or both) ports to be set through properties, then this concept might not be the ideal; and honestly, from a developer perspective, I think it is much straightforward if we only have to set the base port and know that the concurrent run just has to be X ports away from the first run.