Note:

• Those are internal engine changes ideas. Nothing here is about PHP userland API, but engine API/ABI.
• Do not break if it is not needed.
• Think about global changes, BC breaking, that could possibly be kept for about 10 years (we don't know yet if when will happen the next major)
• Design clever, for good, not evil

Initial factors to be taken care of:

• number of contributors
• timetable (2 years development)

• Cleanup API and dead code
  • Clear namings
  • Clear conventions between macros and functions
  • Clear those

• Define a true C/C++ API
  • Be able to export the engine in its own .so
  • Decouple the engine from PHP and SAPIs( https://wiki.php.net/rfc/php_native_interface - https://wiki.php.net/rfc/remove_zend_api)

• Keep the extension-based build. Smaller pieces, better code maintaining
  • Merge SPL to the engine (at least, deep engine related stuff in SPL, such as the exception classes, the iterators and the functions like class_parents())
  • Rework Phar. Phar has too many engine hooks and voodoos, this must be rethought

• Ehance extensions power
  • Keep distinction between zend extensions and php extensions ? https://wiki.php.net/internals/extensions
  • Use of other engine hooks ? other VM hooks ?

• VM
  • Executor rewrite
    • JIT executor
    • Threaded VM
      • IO threads ?
      • Do several things at the same time, stop blocking
    • Get rid of those patches applied for years to keep BC ( )
  • Compiler rewrite
    • reentrant
    • AST based
    • Hookable AST for optimizer passes
  • OPCache integration
  • OPcode binary data based compiler (phalanger, phpcompiler.org, bcompiler, roadsend)

• Arrays/Objects struct data sharing
  • Use array_* functions with objects or arrays

• MM rewrite
  • Different pool sizes
  • Different heap allocators ? (jmalloc ?)
  • GC thoughts

• Improve debug
  • Improve DTrace usage
  • Give Linux process-probes a try (SystempTap, perf, OProfile)

• See also
  • Global PHP6 ideas
  • http://hg.python.org/cpython/file/
  • http://morepypy.blogspot.fr/2009/03/applying-tracing-jit-to-interpreter.html