In my Penknife draft, there's a calling rulebook, extensible just like any other core rulebook. To resolve the paradox, two callable types are built in: Functions and rulebooks. The core calling behavior tries those two cases first, then finally calls the "rb-core-call" rulebook.
If someone replaces rb-core-call with something other than a core function or rulebook, they'll get an infinite loop, and it'll be their own fault.
I think Arc could easily be patched for something like this: Just change the "Function call on inappropriate object" error message so that it calls an Arc function that raises that error message instead. We could call it 'custom-call, or maybe 'defcall-missing. :-p
"Rulebook" may actually be a bad name for it, 'cause there are more complicated notions of rules. I chose the name because I considered it to be a simplified form of Inform 7's rulebooks, but I might have simplified the "rule" part right out of it.
In my Penknife draft, every function can either return a value, raise an exception, or fail with a failure message. Failure means the function doesn't meaningfully apply in this case, and it lets the caller try something else if they they happened to use failcall to provide an alternative. If they didn't use failcall, it just raises an exception.
A Penknife rulebook can be called as a function. It's represented by a sequence of functions that are called one at a time until one returns a value or raises an error. If they all fail instead, then the whole rulebook fails.
A rulebook is like a series of 'extend cases, but being its own type, it's less encapsulated. There could theoretically be rulebook utilities that let you count the number of extensions, etc. While an implementation of 'extend could do this too, it's a little unheard of.
The exact implementation of a Penknife rulebook is kind of up in the air at this point. I was just using a box with a list of functions inside, but recently I've been considering focusing all of a module's mutation onto one easily swappable place, rather than having it spread out over a namespace and an arbitrary number of rulebooks, global tables, and other such things.
So... that sounds an awful lot like message passing + prototypes. So much so that I'm fairly sure you could create rulebooks as syntatic sugar on top of message passing + prototypes.
And if rulebooks are sugar on top of prototypes, and the built-ins are implemented with message passing...
