You likely have opcache enabled on one version and disabled on the other. Is that the case?

I had ASSUMED that to be the case. 
But then I reproduced the problem even after I updated the PHP.INI to comment out all caching includes, and restarting the web server:

;zend_extension=php_opcache.dll

[XDebug]
; Must be loaded after OpCache !
;zend_extension = "C:\Program Files\PHP\v7.2\ext\php_xdebug-2.7.2-7.2-vc15-nts-x86_64.dll"
xdebug.coverage_enable=0

[PHP_WINCACHE]
;extension=php_wincache.dll

this behavior seems pretty consistent: https://3v4l.org/GnDr2

Thanks for that test. So in my attempt to strip down the code of my (possibly SECONDARY problem) to the bare essentials, I unintentionally may have stumbled on the the more generic, primary problem?

Now that it's reproduced in all PHP releases, is this accepted as an unintended behavior/bug?

PS: My ORIGINAL problem occurs in a complex application (a Plug-In file in a WordPress environment), where the "test script" code itself is part of a deep multi-level code and include sequence in WordPress.

In my "real" problem, the code that is unable to reference the subclass (demonstrated by the "class_exists(...);") is actually inside a function that gets called much later by WordPress in its execution order. Lucky for me in that combination, the PHP parser will have already parsed the entire script (including subclass that extends an included class) before the function is ever called, effectively MASKING the above problem.

But, my production code has a "return;" statement BEFORE the subclass definition. I have the suspicion that given the primary problem you reproduced, there is then a secondary problem when OPcache is running: With OPcache running, the entire script appears not be parsed unless I remove the "return;". That then UNmasks the primary problem of extending parent classes that reside in includes.

The VLD output[1] hints at what's happening.  The point is that
PHP first compiles a file, and runs it afterwards.  When it
compiles the main script, myClass1 and mySubClass1 are fully
defined, and so can be linked.  However, mySubClass2 cannot be
linked, because myParentClass is not yet known.  Then the main
script is run, starting with including the file where
myParentClass is defined; then the script proceeds to the first
var_dump() where mySubClass2 is still not defined, because it is
only linked afterwards (see the ADD_INTERFACE opcode). For the
second var_dump(), all classes are defined.

Well, bug or not a bug?  Let's say wont-fix.  That is just how PHP
works.

The best *general* advice to never face these kinds of issues is
to never mix declarations and execution logic[2].  And then rely
on autoloading, to avoid loading classes you don't need.

> With OPcache running, the entire script appears not be parsed
> unless I remove the "return;".

I presume you're hitting OPcache's optimizer's dead code elimination
here.  The code after the `return` is never supposed to be executed,
so isn't even compiled (practically).  I think you can deactivate
DCE with

    opcache.optimization_level=0x7FFE9FFF

[1] <https://3v4l.org/GnDr2/vld#output>
[2] <https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-1-basic-coding-standard.md#23-side-effects>