Testing with #5088 merged things still don't work correctly. However, changing the internal handler from the JSessionHandlerJoomla object to JSessionHandlerNative does result in sessions working correctly for the whole system. So our issue is narrowed down specifically to the startup sequence our code.

Long and short, the issue relates to the use of JInputCookie. It is reproducible at the Framework level using the master branch of https://github.com/mbabker/session-test as well which uses the Framework version of JInputCookie. Running a test case with a proposed rewrite of the Session package using my repo's v2 branch (which isn't using the problem class) has the session at least booting up but the internal counter is incrementing twice for each hit instead of the intended once.

Something went wrong when use linked $_COOKIE in JInputCookie constructor:
works:

// Set the data source.
$this->data = $_COOKIE;

not work:

// Set the data source.
$this->data = &$_COOKIE;

It looks like that's a distinct possibility then which would affect all of the JInput classes (that change isn't really well documented in the upgrading guide unfortunately).

So, I guess my first logical question would be what are the implications of changing JInput to not use a & reference to the superglobals?

do not use & most simple/obvious solution

but if it really PHP 7 bug, then maybe we have a chance to get it fixed,
I just not found how to confirm it, how to write some sample code to reproduce the bug

Let me spend a little time building a small app in pure PHP following our construct logic and we'll see what happens.

https://github.com/mbabker/session-test/blob/purephp/index.php

That file is a minimalistic script using our session boot sequence, I can duplicate the issue with accessing $_COOKIE by reference with it and removing the reference character gets things working fine.

I guess a more accurate script would have also accessed $_REQUEST by reference as the base JInput does by default, but this is close enough to cover our needs.

I can confirm it also,
now it more clear that it is PHP 7 bug

I've submitted https://bugs.php.net/bug.php?id=69952 - we'll see what they have to say about it.

The upstream bug has been fixed and I've verified things are working as expected with the 3.5-dev branch using the PHP 7 VM linked above on the current PHP master branch.