nested state machines

Why we need it?

If we face interactive command like openssl:
https://www.openssl.org/docs/manmaster/man1/openssl.html
https://wiki.openssl.org/index.php/Command_Line_Utilities (search "interactive mode")
then we may end up with something that may be started in multiple states of typical Moler device. openssl may run inside UNIX_LOCAL, PROXY_PC, UNIX_REMOTE.
Moreover, running interactive command introduces its own prompt (OpenSSL> for example). It finishes running openssl command but after it you can't run normal linux commands, just those of openssl. So, it constitutes state of device State Machine. We might introduce new state into existing devices but:

1. that would require complicating state machine
2. require to do same change in multiple machines since such cmd might run from different states
3. adding next interactive command would require the same effort of even more

Concluding: such solution would generate exponential effort, unreadable code and maintenance nightmare.

Comments following below are results of days lasting discussions and analysis. It will discuss:

1. possible solutions (benefits and drawbacks)
2. selected solution
3. analysis of moler current code and changes required to implement that solution

Start with the OpenSSL interactive-mode references and trace the UNIX_LOCAL, PROXY_PC, and UNIX_REMOTE states in Moler's device state machines. The issue says the current code and required changes need analysis, but it does not name files, tests, or a concrete implementation, so confirm scope and acceptance criteria before coding.