The way I’d do parallel vs serial goals is to have multiple triggers/missions and allow for some of them to be dependent on others. Parallel goals are simply the normal list of goals in the mission class that are && together, while serial goals would be represented by two or more missions where one is dependent on the previous ones.
For that example, it might be something like this:
Mission 1 (aka Mission part A) Conditions:
Goal 1: Go to location(x1,y1,z1) (state can be in progress or accomplished)
Goal 2: Guy G is alive (state can be accomplished or failed)
Mission 2 (aka Mission part B) Conditions:
Goal1: Trigger 1 has been accomplished (state can be accomplished, in progress, or failed)
Goal2: Kill the boss (state can be in progress or accomplished)
Only once Mission 2 is accomplished, will the player be given the reward or whatever other actions you want to trigger for the overall mission. This way, everything isn’t necessarily organized in the same object (although you could have a container class that contains the various serial goals that make up a mission) but it will give you a lot of flexibility in creating missions with many stages, continuing conditions, and dependencies.
I scrapped the parallel/serial goals to a cleaner design, similar to what you suggested.
Now I have three classes:
SubMission - A container of Goals. (this serves as the parallel goals I had earlier)
Mission - A container of SubMissions, which must be completed one after the other (this serves as the serial goals).