Hmmm… Are there any examples in the built in Io files where message(x) is used in a way which doesn’t need a clone afterward? If not, perhaps message(x) should have a clone built in.
Also, should this even be implemented in C? It could be implemented in Io code instead:
Object message := method(if(call argCount > 0, call argAt(0), nil))
Or with a clone:
Object message := method(if(call argCount > 0, call argAt(0) clone, nil))

Io now no longer builds. libs/basekit’s Makefile now has the line, "include Makefile.lib", but there is no Makefile.lib in libs/basekit. When the include line is changed back to the old "include ../../Makefile.lib", Io builds again.
The issue is due to shipping libbasekit as a separate library. When shipped independently, it can’t rely on using Io’s ../../Makefile.lib, however, when inside Io, it should use Io’s ../../Makefile.lib. Perhaps a solution is to have Io probe for ../../Makefile.lib (or detect if it is running as part of Io) and use it, otherwise fall back to a simpler local copy.
The idea of having two copies of Makefile.lib isn’t ideal. They’ll have to be kept in sync to some extent.

Hi why, A few small patches:
* Adding core/config.h to gitignore. https://github.com/quag/potion/commit/c370cfefc8bbd5704976a1fc5abf270d21c11d89
* Removing commented out op printf from vm. https://github.com/quag/potion/commit/094aa55a0deb651abbfdd6becf6f020f4a556064
* Grouping details about op codes in compile.c. https://github.com/quag/potion/commit/49508715d3b544276f6c8adfe8e4d786614746ae
Thanks,
Jonathan.

As another data point, Io’s exceptions are implemented on top of coroutines. Doing a try catch runs the code in another stack. When a throw occurs, the coro exits and returns control to the calling try. Kind of expensive, and bypasses that whole stack unwinding thing.
If there is already another powerful mechanism (coros, continuations and so on), then it can save on effort to reuse the existing heavy lifting.