There is some complications that occur with that inspector, and I don’t fully understand all of them but perhaps @AlanM could weigh in.
Consider that when evaluating whether any fixlets are relevant, that could include the current fixlet and thus might not be deterministic. There are also context switches that happen in the client while evaluating any given fixlet - “action” for example may be initialized to the current action.
In general I’d avoid trying to use “fixlet”, “action”, etc. as part of fixlet evaluation - they won’t work as you expect, and are intended to be used by things like the Client Compliance API. Perhaps you could check in to whether there’s a Client Compliance API methid for what you want, where (on the client itself) you “tag” a machine as being ready for the next baseline, which is basically the breadcrumb approach yoy reference.
Maybe we can also revisit why you’d need multiple baselines, or for them to run in sequence. If there is a dependency on order among the components, we’d generally want to keep them in a single baseline instead so the ordering can be enforced.
One method I’ve done (not proud of it, wouldn’t do it again) was that I needed to tell when “all” of a set of baselines had completed so I could trigger a single reboot at the end. Those “fixlet” and “action” inspectors that don’t work during fixlet evaluation, I found do work within an Action. So I had a policy action running every hour while outside of my maintenance window, and every 15 minutes while inside of the window, that would use the “action X” and “fixlet” inspectors. Based on the results, I’d tag client settings on the machine and then use those settings values in my relevance for “reboot the machine” and “close maintenance window” actions.