By older version presumably this is only from Joomla 2.5? Otherwise I don't understand given $this->input is in the controller since Joomla 3.0.0

Sounds like that. The problem is that we now force to relogin and in that state it could be possible working on the old lib files.

If we can confirm this as a 2.5 to 3.x upgrade issue, it's a valid bug fix. If this is an issue on a 3.x to 3.latest upgrade, there is another bug and this is just masking it.

Class member properties should be able to be relied on to be set, if they aren't being set correctly there is something really awkward happening. In the case of a 2.5 to 3.x upgrade, that problem is probably related to the autoloader and the JControllerLegacy class being read out of libraries/cms versus libraries/legacy (which would happen if during the upgrade you have to hit the supplemental login screen, at that point the deleted files step will not have been triggered) and this is an appropriate bypass. In general though, any place where we have to do what equates to a $this->foo = $this->foo ?: JFactory::getFoo(); call then we're hitting problems that need to be clearly documented.

If we can confirm this as a 2.5 to 3.x upgrade issue, it's a valid bug fix. If this is an issue on a 3.x to 3.latest upgrade, there is another bug and this is just masking it.

IMO the problem is that this kind of issue depend on server setup and how fast your server are. So this is nothing we can reproduce by a simple test. IMO based on the error report this is a valid problem with a known fix.

To me this is still blindly patching issues without understanding root cause. If a class member property is set in a class' constructor, a class method should NEVER have to check that the property is actually set (otherwise it defeats the purpose of doing it in the constructor to begin with).

So while the fix may be valid, I don't feel comfortable merging something like this just because it might fix some issue that some people might be having but we have no idea what or why.

but we have no idea what or why.

The why is simple. ;) Your filesystem was not fast egnoth to replace the files and load the new class. So the property was not set and can't be used.

In this special case we are just inbetween the update and the cleanup task which remove the old files is not run yet. So this would explain the issue.

On what upgrade path though? The property has existed since 3.0.0 and it was somewhere around 3.5 or 3.6 where we started deleting files in the restore.php file. So it has nothing to do with the system being fast enough to delete stuff, it is a very explicit upgrade path that triggers the issue and THAT is what needs to be clarified here.

If it is a 3.x to 3.x upgrade, there is another bug that needs to be addressed, this is only hiding another issue. The only upgrade path this change might affect is a 2.5 to 3.x upgrade.