Hmm… should be obvious, but if you do a GUI for class creation, it would be nice if it could be exported/imported from some text-based format like XML, or even just having it’s “native” format be a script kinda like what I suggested earlier. This would allow one to use tools like BBEdit to do bulk transforms for refactoring purposes, or for automating data import. You’d be surprised how often I’ve wished I could do that when working in FileMaker Pro’s GUI based scripting system.
Also, I think it’s important to have the ability to export all the data that’s stored in a stack file including custom classes and object instances; or have the base file format be easily parseable. From time to time, I’ve been asked by someone to help when they’ve put years of data into a database or application, and reached the end of it’s capabilities; only to find that getting that data out in a meaningful way was sufficiently difficult that I had to tell them to type it in again. Or worse; the publisher goes out of business (be that due to a lack of cash, or due to being bought up and killed by a competitor) and eventually the old hardware dies, and they can’t migrate forwards.
This is, FWIW, why all my apps’ native file format is JSON, compressed with ZipKit’s inflate/deflate routines; and there’s also an uncompressed option in the open/save operations.
Personally, I really do think it should have a lightweight type system; even if you go with a factory-method style OO system. By that I mean that an object should have an “is a” property that can be queried and filtered for; and a set of protocols that can also be queried and filtered for. I would avoid multiple inheritance as that gets messy fast.
This is the sort of thing that a power user would find useful, but a basic user need not be concerned with just to tie some actions together.