If you only want to curry some of the methods into subs, you can always fall back on function currying, the syntax of which is run-time-ish, so how you pick the functions to curry and how you then bind the new functions to names is external to the curry itself. It would still be possible to hook this into the "use" apparatus, since that has built-in the notion that it is constructing a view of something elsewhere, so a module that you think of as Foo can be a version of Bar with all the names and arguments messed around with.

As for having to repeat the class name, yes, that's currently an issue, particularly since you have to declare the type of your $defobj before the use. But I think I mentioned the current syntax is still negotiable, and would certainly be open to suggestions for syntax that is both composable and succinct. We could go as far as to have a variant usesingle that autocurries a singleton, but then we have to decide how it composes with the filters you also requested above, and where the singleton object ends up getting stored, if it's to have some kind of user-accessible name. For composability there are times you might want to return the singleton, and times you might want to return the class's protoobject. It's difficult to do both of those simultaneously.