If only users of good software would propose good solutions to the folks that write that good software, these issues probably wouldn’t persist 
How would you propose something be implemented to “sometimes” install v24 and “sometimes not”? To me, this is really the underlying problem here that I can’t say I understand. If you can describe when/why v24 is actually needed and when it is not, then coming to a solution is much more likely to happen. As it stands, I don’t know how I could reproduce the issue in order to propose a solution that improves the status quo. All I can see is “if I assign v24, then it is required.” But, that doesn’t really tell the story completely–we don’t even know what software you’re actually talking about.
I also get the “needing to install things in a certain order,” but what do you propose the behavior of Immy should be in the event that one of those items fail if you don’t create a “dependency chain” (as @Dakota_Lewis described, which I agree with) besides stopping/failing the entire session over it?
Why does v24 fail to install? Is that something that’s addressable?
I wouldn’t really care for the appropach of aborting the session, but you could create a task that checks for successful installation of v24, and if it fails, abort the entire session.
Alternatively, you could write a test for v32 to uninstall/reinstall if it detects that v24 was installed on a later date/time than v32. But, I don’t know if that also means the final application needs to be reinstalled as well? (And if so, a similar test could be written for that software also).
Trying to help out here–but the necessary details to help are just not there–and also seems like the dependency chain already solves the problem, other than the “sometimes” problem that hasn’t been defined.
One “feature” that may get you what you want is the concept that I’ve floated with @DarrenDK a time or two that I call a “Deployment Group” that is an ordered list of deployments that can have an overarching set of parameters that feed into the parameters of the deployments within the group.
Then, there is a feature being worked on called “Child Actions” that allows a single task to create “children” that each report their own compliance (think Windows Updates, and the child actions are all of the individual windows updates being installed).
Not sure if any of that helps you at all, but if not, give us some more specific details so we can try to understand how to effectively solve the problem with Immy.
