I can't reproduce this. How did you detect these leaks / in which form did they manifest?

Ah, seems like I specified USE_ZEND_ALLOC=0 incorrectly.

Now getting this valgrind output for the require inexistent file case:

==8944== 
==8944== HEAP SUMMARY:
==8944==     in use at exit: 68,745 bytes in 2,588 blocks
==8944==   total heap usage: 27,424 allocs, 24,836 frees, 1,842,625 bytes allocated
==8944== 
==8944== 136 bytes in 1 blocks are definitely lost in loss record 69 of 138
==8944==    at 0x4028876: malloc (vg_replace_malloc.c:236)
==8944==    by 0x850BF34: _emalloc (zend_alloc.c:2423)
==8944==    by 0x84E40D2: compile_file (zend_language_scanner.l:548)
==8944==    by 0x82E4393: phar_compile_file (phar.c:3391)
==8944==    by 0x84E4419: compile_filename (zend_language_scanner.l:622)
==8944==    by 0x858A90A: ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER (zend_vm_execute.h:2592)
==8944==    by 0x85806C8: execute (zend_vm_execute.h:410)
==8944==    by 0x8545111: zend_execute_scripts (zend.c:1272)
==8944==    by 0x84A8624: php_execute_script (main.c:2473)
==8944==    by 0x868E8D0: do_cli (php_cli.c:983)
==8944==    by 0x868FC4F: main (php_cli.c:1356)
==8944== 
==8944== 211 bytes in 1 blocks are definitely lost in loss record 77 of 138
==8944==    at 0x402896C: realloc (vg_replace_malloc.c:525)
==8944==    by 0x850C08F: _erealloc (zend_alloc.c:2444)
==8944==    by 0x84AC6F0: xbuf_format_converter (spprintf.c:777)
==8944==    by 0x84AC9DC: vspprintf (spprintf.c:799)
==8944==    by 0x84ACA3D: spprintf (spprintf.c:818)
==8944==    by 0x84A3CEC: php_verror (main.c:832)
==8944==    by 0x84A3FDC: php_error_docref0 (main.c:865)
==8944==    by 0x84A5642: php_message_handler_for_zend (main.c:1372)
==8944==    by 0x8543DE6: zend_message_dispatcher (zend.c:972)
==8944==    by 0x84E41AD: compile_file (zend_language_scanner.l:568)
==8944==    by 0x82E4393: phar_compile_file (phar.c:3391)
==8944==    by 0x84E4419: compile_filename (zend_language_scanner.l:622)
==8944== 
==8944== 252 (136 direct, 116 indirect) bytes in 1 blocks are definitely lost in loss record 80 of 138
==8944==    at 0x4028876: malloc (vg_replace_malloc.c:236)
==8944==    by 0x850BF34: _emalloc (zend_alloc.c:2423)
==8944==    by 0x84E40D2: compile_file (zend_language_scanner.l:548)
==8944==    by 0x82E4393: phar_compile_file (phar.c:3391)
==8944==    by 0x854500D: zend_execute_scripts (zend.c:1264)
==8944==    by 0x84A8624: php_execute_script (main.c:2473)
==8944==    by 0x868E8D0: do_cli (php_cli.c:983)
==8944==    by 0x868FC4F: main (php_cli.c:1356)
==8944== 
==8944== LEAK SUMMARY:
==8944==    definitely lost: 483 bytes in 3 blocks
==8944==    indirectly lost: 116 bytes in 4 blocks
==8944==      possibly lost: 0 bytes in 0 blocks
==8944==    still reachable: 68,146 bytes in 2,581 blocks
==8944==         suppressed: 0 bytes in 0 blocks
==8944== Reachable blocks (those to which a pointer was found) are not shown.
==8944== To see them, rerun with: --leak-check=full --show-reachable=yes
==8944== 
==8944== For counts of detected and suppressed errors, rerun with: -v
==8944== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 35 from 6)

I'm not sure how expected or not this is. All your cases are ones which will cause a zend_bailout and unclean shutdown. I'm not sure those can really be cleaned up correctly.

Closing as not a bug. After talking to Rasmus it seems like it is intended behavior to not free all individual allocations on shutdown and instead rely on the Zend MM to flush all allocated memory.