I don't see anything recently suggesting a similar problem or any changes in the product (though I may have missed something). I suggest filing a WRC issue for this for a more detailed investigation, but I'll give you my best guess here:

I suspect you typically start/stop the instance as a user that is not an Administrator. When you did the upgrade, you did so as an Administrator, and that left the instance running, started by an Administrator. The difference in which user started the instance likely caused the problem shutting down as another user. Given that, I'd expect that subsequent startups as a non-Admin user would allow for shutdowns also as a non-Admin user.

If this isn't the case, please provide the cconsole.log and the Caché SYSLOG ('do ^SYSLOG' from the %SYS namespace) to the WRC, and we'll be happy to help.

I suspect that the database has 2 KB block size. It would be mountable in 2008, but not in 2014. If you still have access to the 2008 system, you can run GBLOCKCOPY to convert the database to 8 KB blocks.

You should definitely contact the WRC about this. We will definitely want to look at your cconsole.log file. My best guess without much information is that a Caché process died abnormally (was killed at the OS level, or some other way that it wouldn't go through Caché halt codes) while holding onto the resource that controls access to the PID table. This basically prevents any new processes from being created. 

You'll likely need to run 'ccontrol force cache' to get the system down, but please collect a CacheHung report beforehand (a script in the /bin directory of the instance) to provide to the WRC.

These messages generally mean that a process is trying to run a routine as it is re-compiled, and the kernel realizes that the routine has changed out from under it. They don't necessarily indicate a problem, hence the informational 'level-0' message.

I think this is a better question for support. I recommend opening a WRC issue for this.

You want to use the condition parameter of zbreak. Take a look at this code:

zTestDebug
s x(1,2,3) = -2
s x(1,2,3) = 1
s x(1,2,3) = 3

If I do the following with zbreak:

zb *x:"B":"$g(x(1,2,3))>0"

This just breaks if x(1,2,3) is greater than 0. Then execute the routine, this is what happens:

%SYS>d ^zTestDebug
 s x(1,2,3) = 1
 ^
<BREAK>zTestDebug+2^zTestDebug
%SYS 2d0>g
 s x(1,2,3) = 3
 ^
<BREAK>zTestDebug+3^zTestDebug
%SYS 2d0>g
%SYS>

You can add an argument to $zf(-2) such that the child PID is returned in $ZCHILD. This is documented here. For reference:

s rc=$zf(-2,"program","","",1) 
s childpid=$ZCHILD 

Security.Users Export method is what you need. It does allow you to specify usernames or roles to export. From the docs:

 classmethod Export(FileName As %String = "UsersExport.xml", ByRef NumExported As %Integer = 0, Usernames As %String = "*", Roles As %String = "*", SQLPrivileges As %Boolean = 0, ByRef NumSQLPrivilegesExported As %Integer)as %Status

This method exports User records to a file in xml format.
Parameters:
Filename - Output file name
NumExported (byref) - Returns number of records exported.
Usernames - Comma separated list of Usernames to export, "*" = All
Roles - Comma separated list of Roles, "*" = All. Export Users containing only these roles
SQLPrivileges - 1/0 flag. If 1, export all SQL Privileges from all namespace on this system that have been directly granted to this Role
NumSQLPrivilegesExported *byref) - Returns number of SQL Privileges and SQL Admin Privilege Set records exported

I'm a bit confused by this question. When a failover happens, all the connections to the instance will be forcibly shut down, since the instance will be forced down. 

If you want to do anything to start things up at a specific point in the process of the other node becoming primary, you can put code in ZMIRROR.

Anything launched by $zf(-1) is going to run as the user that is running the original process. In the case of a Caché terminal session, that will just run as whatever user is running the terminal, and there's no way to get around that. 

If you were to use another method to run the $zf command, such as a Telnet connection, or running it via the Caché task manager, the process would instead run as the user who owns the Caché Controller services. So, if you REALLY need to be able to run cmd as an administrator, the best way would be to make the user who owns Caché  the system administrator user, and then run this code via the task manager (you could use a RunLegacyTask).

All that said, I have to agree with Rubens, this is not an ideal setup for security reasons, why can't you just make it such that your executable will run without the need for administrator access? Is there a particular reason why it requires administrator rights?

If you are using the Cube's terminal, you can define a connection (Preferred Server -> Add/Edit) that points to the VIP (assuming that the 2 mirrored instances are using all the same ports). You could then make that the preferred server (Preferred Server -> click on that connection). Then the default behavior for that cube's terminal would be to connect to the VIP address.

However, if you are trying to run scripts on only the primary server, you may want to look into using task manager. You can define tasks to run only on the primary mirror member. You could have the task call out to the script on both instances, and it will simply not run the task if the instance isn't primary.

The concept of a relay server was something built into the original design for mirroring. It was never fully implemented, hence the lack of documentation. There is no way to use a relay server.

I strongly suspect that the code we don't see (from running the routines executed within the task) kills the 'Status' variable. Take a look at this documentation.