We tend not to go that deep in terms of version support. In most cases, we don’t even include a minor version number, but Nuke was the exception due to the number of minor releases it tends to put out.
One of the main reasons is that it’s easier for us to stay up to date on supported versions. It’s also easier for the end user because they don’t have as many versions to configure. Also, while I like the way you set up Nuke.dlinit so that it only needs one executable entry, it does make the assumption that Nuke was installed to the default location (I believe you have the option to change the install folder in the Nuke installer). Yes, I’m sure that 95% of people install to the default location, but if someone doesn’t, this system might not work for them.
I’m glad you were able to modify the scripts to suit your needs though, and thanks for sharing!
I’ve always thought it should try the default naming convention/location for the nuke exe. If it fails then it can resort to the configuration in the repository.
Similar here too, compositors may submit from multiple sub versions, it’s hard to say stick with a particular version when they all have significant and significantly different problems (Ideally foundry would produce more consistent and reliable software, but they seem incapable).