Hadoop is a terrible example to look at, because our versioning there is a mess. Surprising changes regularly show up in double-dot releases and changes that can only be undone with a system rollback happen on single-dot releases. For example I had to argue against changes to the datanode's underlying filesystem layout on a double-dot release recently.
I personally wouldn't want to see this in a 1.6 or 1.7 release for largely the same reasons Josh states. Changing basics around how we do process management on a double-dot release is tempting trouble. It's not this particular PR's problem, but we have essentially no testing around our scripts so any verification of how 'safe' changes like this are essentially come down to some subset of us working through them manually with ill-defined criteria. But I agree with Dave that this kind of change would not violate the letter of our versioning policy, so I wouldn't -1 on principle. If problems showed up after we had a 1.6.z release that contained it I would, however, then strongly advocate for reverting it in later 1.6 releases using the same 'not the public API' argument.
Aren't we getting ready to have a 1.8 release soon? What's so pressing about this particular new feature that means we should introduce risk in our established lines rather than roll forward with more minor releases?
The lack of user-facing docs on what can be expected from this feature, when folks should use it, how folks should use it, etc cause me concern. I get that we pretty regularly have an issue with these kind of "finishing touches" on feature in Accumulo, but it's particularly troublesome to me when these kinds of 'in-the-know' things show up in maintenance releases.
I'd also strongly prefer having the different tserver instances log to distinct files, regardless of what version this lands in. I get that I can use post-processing to figure out which lines correspond to a given process, but I'm skeptical of log4j's ability to efficiently and safely have multiple processes share a log file. This should be doable with a log4j configs since we control the filename via a classpath config file. I don't have strong feelings on how we go about doing that, wether it's example config files that show making a config-per-expected-process (preferably referenced/explained in the user manual) or a parameter in a single log4j config that the launching script sets via a system property.