The problem with Sessions is where they're used. They can be used by any number of objects, across any number of components, across any number of applications. So my main concerns are:
1. Namespaces
2. Storage method
3. Access style (ArrayAccess/OO)
What I really like is to have classes which accept a Session object implementing ArrayAccess from SPL. So it acts like a normal array (which is good for BC) but is actually an object. More interesting, each object does not represent the entire $_SESSION - only a specific sub-array (or namespace) so conflicts are more difficult since older namespacing isn't affected, and can't touch the top-level $_SESSION anymore

. A core Session object held by the namespaced session object can mediate to the storage medium using whatever your preferred strategy (file, MEMORY table or other database) may be, and track each namespace. It should throw some kind of exception if a new Session object with a conflicting namespace is created - allowing overwriting by default probably isn't a good idea.
Why is a wrapper class useful? It acts like an Array and solves the bane of all things global - namespacing, and abstracted storage. The only problem is whether other code will let you hook in a custom Session object or array without making changes. I'd have to say you'd mostly need changes since few consider you wanting to specifically plant a replacement for $_SESSION. Most code will reference it directly - which is a big problem since it breaks enough OO rules to make changing this a messy task.