Cool, thanks for explaining that.
So I poured myself a 
and gave this a shot with the Custom Wizard Plugin.
I checked each tag out one by one in reverse order starting with v2.6.0.beta1. I found these git commands helpful:
git tag --list \\ e.g. git tag --list 'v2.5.0*'
git checkout tags/tag \\ e.g. git checkout tags/v2.5.0.beta7
It didn’t take too long to find a tag that wasn’t working with the current version of the plugin: v2.5.0.beta7 doesn’t include discourse/app/components/d-textarea which the custom wizard tries to import.
So, then I found the commit in the plugin that added that import, took the sha1 of the previous commit, checked that out and tested (worked fine), and added this to .discourse-compatibility:
v2.5.0.beta7: 802d74bab2ebe19a106f75275342dc2e9cc6066a
I then pushed that to a branch with the latest plugin code (a branch for testing, not necessary normally), and rebuilt a dockerized test server with that plugin branch and the version set at v2.5.0.beta7.
That didn’t work, then it hit me that, of course, the rake task plugin:pull_compatible_all doesn’t exist in v2.5.0.beta7, so this isn’t going to work retrospectively (I blame the ). Sure enough in the launcher logs I see
Don't know how to build task 'plugin:pull_compatible_all' (See the list of available tasks with `rake --tasks`)
Is that the gist of how you imagine this being used though?
On the required_version front, I encountered that here as the test server had the discourse-legal-tools plugin installed, which has a required_version of v2.5.0, so it initially failed on v2.5.0.beta7. I think I’ll transfer that plugin over to this new system. I can still see required_version being useful to set an absolute baseline as you say.