Each vessel in an Orbiter scenario can have its own, independently working autopilot. So you can put one vessel on autopilot, then jump into another vessel and try to chase the first or you put the second vessel on autopilot too - many intersting scenarios can be setup this way.
Missions and procedures are stored as XML data in ordinary files. This makes it easy for the user to define new missions, edit existing procedures and even to read/write Flight Operation Plans stored in the files with other applications.
Aside the built-in processors (manoeuvres handlers; currently: Launch, Ascend (Profile), AlignPlane, SyncOrbit, Attitude, Approach, Docking, Deorbit, Reentry, Landing, Transfer and Ballistic) the user can write DLL modules to implement own processors that can be integrated into REDSHIFT. As an example there is a Sci-Fi processor called Warp that comes in its own module.
Although you interact with REDSHIFT via a MFD, REDSHIFT itself is not a MFD in the ordinary sense: Normally MFDs are stateless because they can started/created and stopped/destroyed at will (and Orbiter is actually doing that whenever you switch MFDs). REDSHIFT on the other hand is a Flight Manager that means there must be only one single running instance of it for every vessel in an Orbiter session and it must work even if no MFD or other MFDs are currently displayed (so this part is more like an Orbiter module than a MFD). The MFD part of REDSHIFT provides just a view on the running REDSHIFT Flight Manager for the focus vessel.