Proposed bootstrap for ZF2

application.config.php

<?php
return array(
    'modules' => array(
        'Application',
        /* ... */
    ),

    'module_listeners' => array(
        'use_defaults' => true,  /* false to disable them */
        /* list additional module listeners to use here */
    ),

    'module_listener_options' => array(
        'config_cache_enabled' => false,
        'cache_dir'            => 'data/cache',
        'module_paths'         => array(
            './module',
            './vendor',
        ),
        'instance_manager_configuration_key' => 'configuration',
    ),

    'instance_manager_class' => /* named instance manager here */,
);

index.php

<?php
chdir(dirname(__DIR__));
require_once (getenv('ZF2_PATH') ?: 'vendor/ZendFramework/library') . '/Zend/Loader/AutoloaderFactory.php';
Zend\Loader\AutoloaderFactory::factory();

$appConfig   = include 'config/application.config.php';
$application = new Zend\Mvc\Application();
/* Next line would:
 * - instantiate the requested instance manager
 * - ensure all modules are initialized
 *   - instantiate and attach the default listeners, if using them
 *     - these could potentially be pulled from the instance manager
 *     - these _might_ be passed the instance manager -- this would simplify the 
 *       workflow of the configuration listener
 *   - instantiate and attach the requested listeners, if any
 *     - same notes as above
 *   - the configuration listener would inject the configuration into the 
 *     instance manager at the requested key
 */
$application->bootstrap($appConfig);
$application->run()->send();

send() method lives in Response -- you're still missing the point. Give any type of response, there are n ways to handle it. "Sending it" is just one option.

Why force it in a "dummy init file" which is index.php ?

What you are proposing implies that the only way to change how ZF2 application handles response, is to hijach the mvc process, and create a subclass for each possible strategy - i.e. class HttpResponseBeingSent, class HttpResponseToFile, class ConsoleResponseToStream, class HttpResponseCachedAndThenSent etc. That's absurd. Why do we use MvcEvent at all, when we could subclass Mvc\Application 20 times to implement all strategies and their combinations. (unless you see some other sneaky way of doing what I've brought up)

ps: it was the first thing I removed when building sample Console application, because the response not always reaches the console window, or it's not always of "Console\Response" class. It might land elsewhere, return an exit code and send to error stream or do a thousand other things (which should live within respective strategies).