I think it would be good to implement this system for Velocity as well before merging. With #517, the default Bukkit config will eventually need to be split Spigot/Paper for the hook-paper-reload option. Having a system now that can deal with the shared options between Bukkit/Velocity would be nice for implementing the Spigot/Paper split later.

Additionally, it would be nice to see some automated tests for the config updating logic. With the YamlConfiguration#loadFromString and YamlConfiguration#saveToString methods, I imagine these tests could look something like:

String currentString;
YamlConfiguration currentConfig = YamlConfiguration.loadFromString(currentString);

YamlConfiguration updatedConfig = ConfigGenerator.generateWithNewValues(currentConfig);
String updatedString = updatedConfig.saveToString();

assertEquals(expectedString, updatedString);

Tests could include making sure new config options are added, extra config options are removed, options set by the user are carried over, comments are updated separately from values, etc.

Putting both these ideas together, writing tests could be easier if ConfigGenerator was able to do more than just generate the default Bukkit config. Each test could pass in its own custom small set of config options, which would mean expectedString wouldn't need to hold the whole Bukkit config.yml every time.

I haven't really looked too deep into how the code works, but it looks good. I just highlighted some inconsistency

Another miscellaneous thing I noticed while testing that didn't fit anywhere else. If I have a config that looks like this:

Once running the server the config gets updated to this:

This doesn't seem like a big deal since - Essentials: null seems to be interpreted the same, but I thought I'd bring it up.

Automated tests might've caught some of the things I brought up, and perhaps more that I missed.

Functionality seems good, so just some comments on code logic and organization.

I still think it would be good to get some unit tests to make sure all code paths and edge cases are verified.

Suprise merge lol, didn't realize we needed to merge this soon.

None of these are big issues, but I would have preferred a third opinion on a few conversations: #596 (comment), #596 (comment), #596 (comment), and unit tests. When I have my own idea of how I would implement a system, its hard for me to tell if these are real concerns or just silly me problems :P.