The early discussion talked about yaml and .properties.
This may be moot, but I'm going to say it anyway. Hopefully we can avoid any flamewar, or at least that it will be brief: Unless we're going to switch the entire config system to yaml, I think it would be a bad idea to introduce yaml configuration for this. My objection has nothing to do with the format itself. Solr already has too many different formats for config files, we should not introduce another one unless that introduction actually reduces the format count – but if we're going to consolidate everything on a single format, I think it should be json. On the idea of using .properties: Solr already uses that format for configuration in other places. That format is perfect for key=value settings, and it is completely cross-platform. It is also handled natively by Java. Later it looks like the decision is to go with a .conf file that is pretty much identical in format to the current solr.in.sh script. As long as the operation is bulletproof with that format on both Windows and Linux, and we don't increase the number of different ways that things have to be configured, it may be a reasonable approach, though I think .properties may be better.
Format aside: I haven't had a chance to apply the patch to verify the end result. I did notice that in the "defaults" config, SOLR_STOP_WAIT is set to only ten seconds. That should be 180. I realize that the "sample" config has it at 180, but it shouldn't take explicitly setting the value to get the current default. Ten seconds is not enough time to wait for Solr to stop unless it's a very small installation, which is why the value was bumped to 180. It rarely actually takes three minutes to stop or start Solr – the shell script will continue before then if it can. The cmd script needs improvement in this area. I have done some experiments with getting the same "waiting up to N seconds" behavior on Windows, and I think we can duplicate it.
Unless I just overlooked the code, it does look like there's no attempt to parse or convert an existing solr.in.* file. I think we do need to handle a minor version upgrade, probably by converting an existing script to a .conf file.
On the changes to the service installer script, I notice that if $SOLR_VAR_DIR/solr.conf exists, it is moved into the service-dependent /etc/default file without checking to see if that file already exists. This could cause problems where a user's carefully crafted config file is destroyed by a service install/upgrade. I don't know how likely that situation is in the wild, but it is never a good idea to blindly move/copy config files, not knowing whether you're overwriting something that already exists. I can see that the existing service installer script also does blind config file copies. Since we're changing things, this is an opportunity to do better.
Another thought: I think it would be a good idea to move a lot more of what the solr script does into SolrCLI, including parsing the platform-independent config file, so that the cmd/shell code is very minimal. I need to sit down sometime and see what I can come up towards that goal.
I might have more thoughts after applying and reviewing the patch with a closer eye.