The Fuel components, like core and all packages, will be based upon the Composer/Packagist structure to be installable through Composer. This should also add support for installing non-Fuel packages from Packagist. Fuel based packages are still required to return a loader object and must be loaded in order to be available. All non-Fuel packages with PSR-0 autoloader support can be made available by adding a single Fuel-Composer loader to the stack.
New and more flexible query builder classes, PDO driven, and with better support for different RDBMS engines.
Config values and language will no longer be in one huge container but instead they'll be put into config/lang objects that are linked to the class that uses them. With this should also come specific validations and rewrite rules for config settings to be set with each class - thus unifying the way config parsing happens throughout Fuel.
The current framework core is a collection of classes supporting features that actually warrant a separate package. For example Event, the Query Builder, Session, etc. These classes need to be split off the core, to make the core more compact and manageble.
All statics have been removed from the core and a DiC in combinations with setters is used to provide the context and loading mechanisms.
The old plan for this has been implemented in a separate Static package that offers a static interface to the pure OO Core: Replace multitons with a DiC. Keep the current interface using instance() & forge() but have those powered by a DiC behind the scenes. This means the front classes will lose almost all logic and none will instantiate itself anymore (much like Form/Form_Instance). All front classes extend the same basic class that handles them.
Both currently do not follow the cascading file system, which means the autoloader can not load these classes. Loading is done hardcoded in oil, app classes can not use them unless they use the same code.
This has to be changed so the normal loading mechanisms are used and the classes can be called from app controllers too.
Current profiler is pretty static, monolithic, and from a layout point of view not very handy as it overlays your webpage. We will probably offer a basic profiler in the core offering just the information, and an add-on package that provides visualization.
Refactor the current Unzip class into a driver based archive class, so other compression and package algorithms can be used.
The environmental settings should be static/singleton as they should be considered such (ignoring that fact is just foolish). All non environmental logic should go into an App class that is instantiated for the app to run and sets up your application and handles the necessary bootstrapping.
Everything in Fuel should become a package (including app & core) and modules should be allowed in every package. PSR-0 will become the default but each package can be set to use its own autoloader logic, with Fuel 1.x autoloader included by default. This will also unify fileloading & classloading as those shouldn't be seperated.
Along with this the concept of Modules in FuelPHP will be simplified and no longer be tied to the Application. Modules will be a way of structuring you code and its non class files will fully cascade into its package, the package files themselves taking precedence over the module files when conflicts arise. The concept of an "active module" will be removed.
A lot of the functionality related to generation is still hardcoded in the different oil classes. To make this as flexible as possible, the code needs to be refactored so that all variable code is in templates and generation logic in tasks that can be replaced or augmented by the user.
The current trio is one tangled mess, which needs to be sorted out.
Largely this is already true for the 1.x versions, which are in no way dependent on the ORM for anything. But for 2.0 this will be much more explicit with it being very clear how and when an ORM is being used as the backend or provider for a functionality. The ORM will be removed from the default 'package' and put into legacy mode (meaning we will make it 2.0 compatible, fix bugs but do no further development). Alternative solutions like Doctrine 2 will get as much support by offering connectors to Doctrine entities (or any other 3rd party ORM).
The way to do this will probably be to offer a Model interface that can be used in conjuction with any ORM and requires all the methods implemented that core drivers need to interact with the model.
The ability to generate an admin section for an application, much like the Django administration module.
Remove all application specific code from the current Pagination class, and replace it by callbacks and app templates.
The current Asset class required you to use groups, and options. The usage should be simplified by making the groups optional. The class will be converted into an instance based model which will allow for multiple Asset instances each with their own configuration.
The usability of the Theme class is going to be improved with support for widgets and widget chrome. It will use an Asset instance to access theme specific assets.
Session drivers are too complicated, and too much information in the session cookie that should be stored server-side.
The current Log class allows simple logging to files only, and only in a static way. It has to be replaced by the Monolog library, which allows for multiple handlers, message preprocessors and formatters, so you will have the flexibility to log to whatever you want.
The class has to be rewritten so that in creates an upload class instance per file uploaded, and every file uploaded can be treated individually, instead of the current "batch" mode.