I don't really get what you are suggesting here.
Instead of trying to find a new stable build through a long line of tests, you set one build that to serve as your new baseline. The missions will be broken but you'd at least have the firm foundation from which you can plan out the work to make put them back into
a working order.
With that you can clean up all the little stuff in Debug Log on start-up - which shortens the list of possible error sources from assets, version mismatches in the tables and the like. This will ensure the mission will "broken" only by what it is in itself.
Once that is cleaned up you go into the mission on a Debug Build and note down each instance in the which the mission is now "broken". As soon as you have the events identified that no longer work, you make a mission that only contains the best approximation of the non-functional events you can - depending on what needs to be done that can take different shapes.
Use the isolated testing mission to narrow down as exact as you can what is not working. Then try to match what is suposed to happen with a similar mechanic that can achieve the same objective - even if it is more complex.
A recent example is the bug described here:
https://www.hard-light.net/forums/index.php?topic=97011.msg1907744#msg1907744When it was first reported, I had the player who encountered send me their Debug Log - it gave me the version information for the replication (21.0.0). As it was a reasonable build for players to use, I made it the target build for the fix, regardless what the build was SerRes was originally released on or patched to. I achieved replication on 21.0.0 and quickly was able to find the offending event by comparing the ingame message and events logs.
Then I created a mission to check the behavior of that event's condition in isolation: A small clean mission that contained nothing but the player fighter and capital ship that was needed for the replication of the event's condition. No other ships and only a few events that let me trigger the arrival and departure of the capital ship with the push of a button.
Using messages and subtitles, I build myself a framework there to check the condition in isolation at first (
when-argument with a
number-of list using
cap-subsys-cargo-known-delay). Then as a second step against a similar event (
when using a combination of
and & 4x
cap-subsys-cargo-known-delay), as a thrid step I compared to a variable based solution (5 events using
when and
cap-subsys-cargo-known-delay to
modifiy-variable +1 each for each subsystem; one to trigger if the variable became >= 4).
Turned out that in between the release build of SerRes on a Nightly and FSO 21.0.0 the behavior of the
number-of argument lists was changed, so that the event no longer triggered the way it was originally intended - which is when 4+ subsystem of a certain capital ship were scanned. Instead the event triggered when it was supplied with 2+ valid argument instead when 4+ arguments were valid.
The original event logic would not function under 21.0.0 but an alternative existed and easily achieved. All that it really took was accepting that there was no way to restore the event 1-to-1 but that aiming to achieve the same results through a different approach.
Temporarily I have to suggest to players to get an old Nightly, which still works on the original behavior, for internal development reasons.
Granted, this was an incident where everything alligned perfecty - no scripts were involved and it was pretty simple to isolate what was wrong. For other issues I had to put in additional work to just find what is wrong but it was not hard, it just took the time to prepare the missions with a custom debug overlay that gives the information I require for the situation at hand. Finding an alternative solution to any given event logic is not hard either, most of the time just recreating the original event in the clean mission gives me an idea how to achieve the same results using different SEXP.
And if you are short on time, breaking down the individual steps and keeping a good record of the tasks required helps greatly - I use DIN A3 paper sheets to make my "task boards" so I can pick up and leave a complicated job at will.