The problem at hand:
CI_Session does not allow storing objects.
It does however store a bunch of objects itself which seems like unnecessary overhead (CI object with lots of CI objects and recursions etc).

More detailed: If you store objects (instances of Models in my case) in the Session right now, the data cannot be accessed, because any object you store there will have a “incomplete object error” which makes the data unusable. This is, because the object definitions in the classes (models) is loaded AFTER the session is started.
I would have expected, that auto-loading the respective models would help.

Why this is important:
It simply dis-encourages you to use objects, if your one persistent storage, the Session, doesn’t support keeping these objects. For anything we need to keep in Session, no matter how complex, you force the programmers to store it in arrays or split up in other simply types and, when needed, to feed the session data back into objects that you must create new during script run time. This is bad for performance and creates a lot of overhead.
Also note, that in complex applications, the same objects will have to be create multiple times in different places (unwanted redundancy).

I recently had a problem whereby I needed custom join conditions based on user values. This is not allowed in the join method, as it ends up surrounding the value like so: `'value`', which results in an SQL error. This is easily solved by ensuring that the join() method can support join strings, like so:
public function join($table, $cond = '', $type = '') {
$num_args = func_num_args();
if ($num_args == 1) {
// only 1 arg passed, full join string
$this->ar_join[] = $table;
return $this;
}

The $table argument then becomes a multi-purpose variable (probably worth changing the name also), but this hack allowed me to still use ActiveRecord properly without having to rebuild my whole query as a string, which would ruin a lot of the niceties that I've grown used to.

we need something like http://wideimage.sourceforge.net

right now you cant do zoom crop and other basic image manipulation without writing tons of code, so i end it up always using wideimage in CI

examples:
1)
- you need a thumb (fixed size)
- you upload several images, they have different aspect ratio and sizes
- thumb must be generated without any border left, so you need to resize up if the image is already smaller than the thumb, scale up if its bigger (by choosing one of the axis) and crop the rest

2) you need to resize and merge png images with alpha
- CI doesnt preserve image alpha in several cases

I would love to see application logging in code igniter like as happens in ruby in rails by default.

Here is a snippet from the rails application log (in production mode)

Processing ClientsController#index (for 192.168.1.179 at 2011-12-18 19:27:18) [GET]
Session ID: BAh7CToOcmV0dXJuX3RvMDoMdXNlcl9pZGkGOgxjc3JmX2lkIiVmMGYxMmVj
MWFhNjRiZDg3ODJlNDZjZjY1YzhiZjU5YyIKZmxhc2hJQzonQWN0aW9uQ29u
dHJvbGxlcjo6Rmxhc2g6OkZsYXNoSGFzaHsABjoKQHVzZWR7AA==--4f94c0adec212d51709562b2a6f4996ef0ef5e99
Parameters: {"action"=>"index", "controller"=>"clients"}
Rendering template within layouts/clients
Rendering clients/index
Completed in 0.04318 (23 reqs/sec) | Rendering: 0.03273 (75%) | DB: 0.00295 (6%) | 200 OK [http://testsite.com
/clients]

This log snippet tells me what controller & action are being used, input parameter, how long it takes, and what url has been hit etc.

I would like to use the application logging to improve debugging and for audit purposes to see what a user is actually doing on the site.

1. (at least optionally:) HTTP Cache Headers that match the server-side cache expirations. (Google doesn't need to crawl a page again and again if we know for sure it hasn't changed. Proper HTTP headers would resolve this.)
2. The ability to selectively flush pages from the cache. (I do it with a ?flush_cache query string, but there's probably some better method).
3. Query-string aware.
4. GZip content before caching it and then serve it in its GZipped form to browsers that support decompression (and decompress it for the edge case that doesn't), to cut down on both disk space and processing overhead.
5. Option to minify HTML.
6. And while we're at it, why are the filenames MD5ed? Wouldn't the cache be more readable+manageable if it followed a Controller/Method sub-directory structure? Isn't there a limit to the amount of files that can exist in a single folder before there's a serious performance hit?
7. Mime-type awareness. CodeIgniter should have some way of defining the Mimetype of the output (for example when using CodeIgniter to serve up stylesheets). And this mimetype should be saved when caching the output.