/application
  /models
  /views
  /controllers
/document_root
  /images
  /styles
  .htaccess
  index.php
/library
    /Zend
        Zend.php
        Db.php, etc.
  /PEAR
  /SuperLib

Then users could use svn externals to grab the "library/Zend/" directory and they would get everything they need.

The breakage to backward compatibility impact would be that any usage of this:

require_once "Zend.php";

Would necessarily be rewritten as follows:

require_once "Zend/Zend.php";

But all code invoking the class itself, including static methods and constants, would be unchanged.

Also, the change above could be worked around by adding "library/Zend" to the application's include_path.

Yes, this is a possible solution. PEAR does the same thing, and also stores the PEAR.php file within the PEAR root folder itself. Another solution, would be to rename the Zend.php file to Zend_Util, Zend_Base or something similar, although I am not sure if that would be a good idea?

Basically, Zend.php is inflexible and doesn't provide a mechanism for extension. Some good ideas have been proposed as "plugins" or optional "extras", but we don't have the structure in place for hanging these add-ons to Zend.php as bootstrap-level "plugins". Personally, I prefer Andries suggestion as this gets us closer to this mechanism/structure to support loading optional "plugins" like ZF-151.

Either way, if such change is taking place, I rather see this happen pre 1.0 release.

trunk/library/Zend.php

require 'Zend.php'; // current approach in 0.8 (i.e. works ok now)

trunk/library/Zend/Zend.php

If include_path is 'trunk/library/Zend':

require 'Zend.php'; // works
require 'Zend/Session.php'; // does not work

If include_path is 'trunk/library/Zend:trunk/library', then code above works, but we have an extra component in our include path (not a clean solution - i.e. a hack). The hack is not needed, if developers change their code to require_once 'Zend/Zend.php'. IMHO, changing the include paths is more error prone, risky, and complex "code" to change than changing the code of a ZF app. Also, some situations result in different groups of people responsible for the production environment than the developers who write the code deployed, leading to further complications and headaches when changing external include paths. Thus, some developers might need to add more code to their applications to change the include path on every request

If include_path is 'trunk/library' (i.e. what we use now for 0.8), then we don't need a hack in the include path, but we do need the "hack" of having one line of code in 'library/Zend.php' (require_once 'Bootstrap/Zend.php'), OR developers need to change their code (to (require_once 'Bootstrap/Zend.php'). The approach I suggested works even if developers make no changes.

No matter where the chosen location, it should be noted that either the class must be renamed or the result violates class and file naming conventions. For example, the class in library/Zend/Zend.php should be renamed Zend_Zend, or we break the class name for the file:

Zend/Acl.php  --> class Zend_Acl
Zend/Zend.php --> class Zend?

As a side note, PEAR breaks the same conventions:

PEAR/PEAR.php --> class PEAR
PEAR/Log.php  --> class PEAR_Log

Of course, we could mark the original library/Zend.php as @deprecated, having class Zend temporarily proxy to whatever classes we decide for delegation (e.g., Zend_Util, Zend_Loader, Zend_Registry, Zend_Debug). I believe that this would be similar to, if not the same as, Gavin's suggestion.

I would like to have addressed this before 0.9.0, since we will be more concerned about backward compatibility thereafter, since we are striving for this to be a "beta" (API stable) release.

static public function loadClass($class, $dirs = null
static public function loadFile($filename, $dirs = null, $once = false)
static public function isReadable($filename)

Will move to Zend/Loader.php

static public function loadInterface($class, $dirs = null)
static public function exception($class, $message = '', $code = 0)

Will be deprecated (removed)

static public function register($index, $newval)
static public function registry($index = null)
static public function isRegistered($index)
static public function initRegistry($registry = 'Zend_Registry')
static public function __unsetRegistry()

Will move to Zend/Registry.php

static public function dump($var, $label=null, $echo=true)

Will move to Zend/Debug.php

And last but not least:

static public function compareVersion($version)

Will be supported by Zend_Environment as follows (Simon Mundy):

$environment = new Zend_Environment(new Zend_Environment_Core('framework'));
if ($environment->framework->isVersion('0.9')) {
    // ...
}

In the 0.9 release Zend.php should temporarily proxy these methods, and mark the file as deprecated. A note should be added to encourage developers to update their code according to these changes.

Question is if we all agree on this?

I would add to Andries' outline that we need a class Zend_Version.