.ant-targets-build.xml

Test file relocated to test/jalview/io.

May be worth adding temp.deleteOnExit() in case anything goes wrong with renaming later

Use '.' (test/jalview/io) rather than examples (which should be kept for real user data files).
Or better if possible, use File.createTempFile to save files to a system-managed temporary folder.

exampleLabel (and label.suffix_example_filenames) removed (had been taken out to save vertical space in the Preferences pane).

Is exampleLabel needed? Doesn't seem to do anything.

In BackupFiles it started off as (and remains) simply a boolean flag. Being able to convey that in the user preferences would be too terse so I agree that I wanted to expand that to look like a binary choice. I still wanted it to behave like a boolean flag though to keep the code readable in GPrefences. Also I knew I wanted to do this more than once, and I suspect that if I'm adding anything similar to Preferences in the future I'll want to use it again, it just seemed tidier to bundle it off, with checks and balances, into another class. If I ever have to change those checks and balances I'll be glad it's in a separate class and not spread around GPreferences in multiple places!

Ah I see, yes that is different behaviour.
Though your class is still just wrapping a simple test like

if (trueButton.isSelected()) 

I still think this is not so much a boolean as a binary choice (both options 'mean' something).
And that doing the exact same thing with two radio buttons directly would be simpler.

I'm not sure this is the same. jalviewBooleanRadioButtons.isSelected() should return true only if buttonTrue is selected and buttonFalse isn't selected. It will return false if both are selected (which is not possible[!] but would be ambiguous), or neither are selected (possible but also ambiguous), or crucially if buttonFalse is selected (unambiguously return false). The two expected scenarios are one xor other are selected, with isSelected() returning either true or false. I assume buttonGroup.getSelection() != null will return true if buttonFalse is selected (sorry not had time to check this in reality)? This is how I was wanting the two button radio group to behave like a checkbox but be more visually explicit in the user preferences.

I don't really like creating work for myself, but my experience (in a different arena, so might not apply here) is that scope-creep is common and future features get asked for a couple of years down the line, even when they've been specifically ruled out at the design stage! My over-spec compensatory coding stems from that experience, but I'm happy to believe that occurs less here. I guess I also think a method named "lsBackupFiles" should definitely have the ability to return a list! Now that's changed I guess I don't have to!

Golden rule (for me, but not just for me) is not to write code you don't need (and refactor if needed in the future).
Why not just have a getBackupFiles that returns TreeMap, then Groovy is free to use as it wishes e.g. files.values().iterator().
More flexible than guessing what view of the files might be wanted in future.

Yes! This is the main function, good plan to make it more readable Have extracted two bits of it.

Made some changes from the code review, and attempted to defend the other coding decisions!

Avoid mixing TestNG and Junit (use TestNG)