I think multiple FSMs is the way to go for "gosub" functionality.
Here's an example:
Recently I was working on a sample scene with an RC car control. I started off making one FSM for the controller, but it was getting too complex for my liking. So I split the Accelerator off into its own FSM. The accelerator has it's own states and basically calculates the acceleration at any given time, given user input, deceleration etc. Now in the main Controller FSM, I use Get Fsm Float to get the current acceleration from the Accelerator FSM to apply to the car. What was becoming one quite complex FSM, turned into 2 very simple FSMs.
So when thinking about the subroutine ask if it can be it's own FSM.
Note this also helps you to avoid splitting a state the way you describe. When you send an event to another FSM it is processed immediately then execution returns to the calling FSM. So, for example, you can send an event to another FSM (and data using Set Event Data), and that FSM can run its logic, and control will return after that event is fully processed (all OnEnters have been called). The calling FSM can then get a variable from that FSM, do something based on that FSM's new state (using Fsm State Switch), etc. It's fairly equivalent to a gosub or a function call...
Splitting logic into separate FSMs like this really makes life simpler. It's probably my number one guiding principle in designing FSMs!
Another reason to take this approach is you will generally add states to an FSM over the course of development. If you have to weave those new states into a big FSM it can get messy... but if you've split the problem into parallel FSMs it can be trivial to add these states. Making it easier to add states, even later in development, is one goal of Playmaker (traditionally it gets scarier to add these states because you can't visualize/debug the consequences very easily).
You have a light that you want to turn off/on, so you make a simple On/Off FSM. Later you decide you want to control the light color as well... you could add this to the On/Off FSM, but the states and transitions will start to multiply... or you could make a new Color Control FSM...
Anyway, I think you get the idea. The same goes for states, it's often tempting to keep adding actions to a state even when it would be clearer and more maintainable to add more states. Over the course of a project clarity/maintainability is always worth the extra up front time... And again, if a state feels like it needs lots of actions and needs to run all the time, maybe it should be it's own FSM
In 1.1 all FSM data is stored in a template (missing variables was actually a bug!). Templates are derived from ScriptableObject, like GUISkins. So they are assets that can be backed up, copied etc. But they are binary.
At some point I do want to implement a text dump of a project/fsm (to send with bug reports, to do diffs on etc.).
You can use arrays in custom actions (just declare a public array field), but you can't pass them around as Fsm Variables yet. The plan is to support a List Fsm Variable type that you would add like any other variable in the Variable Manager. We're likely to implement an Object Pool system before that though, which will handle many cases where you need a collection of game objects... But, yes, I want List Fsm Variables too!
Next Frame Event:
This action is most useful when you need to loop through a few states every update without creating an infinite loop. Putting Next Frame Event at the end of the loop breaks you out of the loop until the next update. IOW, the whole loop will be processed once per update.
I'll try to make a sample that demonstrates the idea.
Honestly, I'm a little wary of this action! It blurs the line between FSM and visual coding, and can easily be abused to make messy state machines with no real state, just a mess of "code". I really believe the organizing power and discipline of FSMs help you better build, debug, and maintain behaviors. But I figure it's better to have this action, than not...
-Alex (on e.Kos machine!).