Better python and C++ exception handling/error reporting.
long long support
use Python generic numeric coercion in from_python() for C++ numeric types
Document error-handling
Consider renaming PyPtr to Reference.
Report Cygwin linker memory issues
Remove one level of indirection on type objects (no vtbl?).
Specializations of Caller<> for commmon combinations of argument types (?)
pickling support
Make abstract classes non-instantiable (?)
Support for Python LONG types in Objects.h
Concept checking for to_python<T>() template function (Ullrich did this)
Reference-counting for UniquePodSet?
Throw TypeError after asserting when objects from objects.cpp detect a type mismatch.
Collect common code into a nice shared library.

Testing
    Python 2.0
    object revival in __del__
    More thorough tests of objects.h/cpp classes

Documentation:
    building

    overloading and the overload resolution mechanism

    special member functions

    differences between Python classes and ExtensionClasses
        additional capabilities of ExtensionClasses
        slice adjustment

        Why special attributes other than __doc__ and __name__ are immutable.

            An example of the problems with the built-in Python classes.

            >>> class A:
            ...     def __getattr__(self, name):
            ...             return 'A.__getattr__'
            ...
            >>> class B(A): pass
            ...
            >>> class C(B): pass
            ...
            >>> C().x
            'A.__getattr__'
            >>> B.__bases__ = ()
            >>> C().x
            'A.__getattr__'

    Multiple inheritance

    Correct Zope slander re: MI.

    exception handling

    Advanced Topics:
        Advanced Type Conversion
            adding conversions for fundamental types
                generic conversions for template types (with partial spec).

            Interacting with built-in Python objects and types from C++

            dealing with non-const reference/pointer parameters

        Private virtual functions with default implementations

        extending multiple-argument support using gen_all.py
    
    limitations
        templates
            Yes. If you look at the examples in extclass_demo.cpp you'll see that I have
            exposed several template instantiations (e.g. std::pair<int,int>) in Python.
            Keep in mind, however, that you can only expose a template instantiation,
            not a template. In other words, MyTemplate<Foo> can be exposed. MyTemplate
            itself cannot.

            Well, that's not strictly true. Wow, this is more complicated to explain
            than I thought.
            You can't make an ExtensionClass<MyTemplate>, since after all MyTemplate is
            not a type. You can only expose a concrete type to Python.

            What you *can* do (if your compiler supports partial ordering of function
            templates - MSVC is broken and does not) is to write appropriate
            from_python() and to_python() functions for converting a whole class of
            template instantiations to/from Python. That won't let you create an
            instance of MyTemplate<SomePythonType> from Python, but it will let you
            pass/return arbitrary MyTemplate<SomeCplusplusType> instances to/from your
            wrapped C++ functions.

            template <class T>
            MyTemplate<T> from_python(PyObject* x, py::Type<MyTemplate<T> >)
            {
               // code to convert x into a MyTemplate<T>... that part is up to you
            }

            template <class T>
            PyObject* from_python(const MyTemplate<T>&)
            {
               // code to convert MyTemplate<T> into a PyObject*... that part is up to
            you
            }

            For example, you could use this to convert Python lists to/from
            std::vector<T> automatically.

        enums

        the importance of declaration order of ClassWrappers/ExtensionInstances

        out parameters and non-const pointers

        returning references to wrapped objects

        About the vc6 project and the debug build

        About doctest.py

Boost remarks:

    > > One of us is completely nuts ;->. How can I move the test
    > > (is_prefix(enablers[i].name + 2, name + 2)) outside the loop if it
    depends
    > > on the loop index, i?
    > >
    >   name += 2;
    >    for()
    > {
    >    if (is_prefix(enablers[i].name + 2, name))
    > }

    I see now. I guess I should stop pussyfooting and either go for optimization
    or clarity here, eh?

    ------

    > Re: Dict                                                                      
    >    Why abbreviate this? Code is read 5 or 6 times for every time its          
    > written. The few extra characters don't affect compile time or program        
    > speed. It's part of my personal goal of write what you mean, name them        
    what                                                                            
    > they are.                                                                     
                                                                                    
    I completely agree. Abbrevs rub me the wrong way, 2 ;-> 
 
    -------


                                                                                    
                                                                                    
Later:
       keyword and varargs?
       Put explicit Type<> arguments at the beginnings of overloads, to make them look more like template instance specifications.

Known bugs
      can't handle 'const void' return values
      Who returns 'const void'? I did it once, by mistake ;)