I guess one could say it solves the data inheritance problem - but in an extremely awkward way: the superclass defines the attributes of the subclasses. At least, that's how inheritance is happening in your example.

Yes, this is something I need to think about more. I think it's possible, but the specifics haven't been worked out. (Along with a lot of other ideas).

Much of the power of Closure Objects will depend on how much work you're willing to put into the closure.

First, your closure method eventually stores the attributes in a hash. You are just using the closure to give each object its private lexical hash.

That is how it is currently implemented, but there's no reason why it has to be limited to some access controls and a hash lookup. The technique enforces the "eat your own dogfood" rule (i.e., if you define accessors/mutators on class data, use them even inside the class itself). It allows for a lot of things that would otherwise have to be done by a tied interface.

Frankly, I fail to see how they connect to 'functional programming'.

Closures come straight out of functional programming. Plus I like ideas that combine concepts that are normally thought of as completely seperate.