OK, I guess I should go back from my area where I've recently worked on data/project migration improvements (more about this at bottom of this page) and spend some more hours on scripting stuff.
I think mainly about helping with moving it up to kofficelibs. Contribute with scripting design and implementation and macro bindings, making it easier adaptable for other KOffice apps, most notable Krita.
Sebastian is a chief in our scripting department, his awesome work deserves support. We all need to make KROSS fit well for relatively different apps like Kexi and Krita.
I'll tell this for myself: a main difference you need to know is that we're not fans using automatic bindings for this. User-level scripting won't work this way. Look at how SUN's UNO exposed in StarBasic - it's relatively more ugly to instantiate dozens interfaces impleemntation to get an access to, say, a spreadsheet cell or to get data loaded from a datas source.
It's not how user's world looks like. Users want one, or at most: two API layers - that's all.
They won't love APIs created by casting C/C++ APIs to Python/Javascript/Basic/whateverlanguageyoulike, 1-to-1. Audience for app level scripting is not the same as audience for PyQt/PyKDE. The task of providing must be perfomed by human being, so the effect will be more flat, not so powerfull, but easier to understand and remember API.
The resulting API that use familiar metaphores, like spreadsheet cell or data table row, and lacks many abstract classes and layers virtually nobody will want to study except me and you.
On the other hand, if your power user, "one in a million", complains she/he cannot "override a method class X", feel free to propose her/him just to use C++ (or full PyQt/PyKDE?) so she/he can implement extension in a form of plugin. Or she/he can just contribute her/his code to your app directly. The power user will be able to do so, if it's works of additional work.
In the same time, the rest (or majority) of users will be quite happy not to see bloated scripting APIs.
And finally, for the rest of users, who are not able to do scripting but want automation, we have macros
- even more simplified version of the original API, most often allowing only linear step-by-step processing (i.e. no looping and algorithms) - simple and easy to understand.
