As an alternative to (1) something similar to std::panic::set_hook can be implemented, so the expected panic functionality (as in printing AlertCode and terminating) is preserved and not left to the mercy of the app.

If you haven't seen it yet, I suggest reading the libtock section of libtock-rs' Overview page. In retrospect we should probably add the following sentence:

Using libtock is not a requirement for libtock-rs users; we expect that many users will find libtock's choices unsuitable for their use cases. Those users should use the underlying crates (libtock_platform, libtock_runtime, etc) directly.

libtock is provided as an easy way to get started with libtock-rs. To make it easy, it makes a lot of choices for the user, such as which panic handler to use by default. In other words: libtock does not currently support other panic handlers, but libtock-rs does.

I do think that adding an app_defined_panic option is reasonable, though: it is simple and low-maintenance.

With respect to adding string-printing functionality to the LowLevelDebug syscall API: I don't think that is a good fit. I developed LowLevelDebug at a time when I was trying to get relocation working. Printing a string was not possible because pointers were not working. That's why I implemented LowLevelDebug: Console, which is normally the debugging tool you would use, wasn't available. LowLevelDebug was never intended to be a part of production Tock systems, only a debugging tool to use when nothing else works.

Currently, the Console driver is the correct place to output debug messages. That said, maybe having a separate output stream for error messages is sensible (Unix has stdout and stderr, after all). I'm not sure if that is worth the extra code size + RAM usage, though, for a system as lightweight as Tock. It depends on the use case of course, so making that an optional feature seems reasonable (for users who want it).