I wanted to give you a heads up on an impending plan, and get your input about it--based on your experiences and what directions you might have seen for the FFI.

The direction I'm moving in is to get everything under one FUNCTION! type, where the sub-behaviors are based on a couple of bits in the type-specific flags. It's not too hard to imagine the user understanding that a "NATIVE!" is a function that perhaps when you say BODY-OF and it doesn't give anything back (or gives some internal identifier, like an ISSUE of #45 or something like that) However, ROUTINE! is a bit different.

So it got me to thinking about how it might be done another way. This other way would be to have a single FFI-dispatch "native" which took a description of what to call and then a function frame to decode. So for instance imagine there were no ROUTINE! but something more like a MAKE ROUTINE! that produced something like:

gtk-init: func [argc [integer!] argv [integer!]] [
    ffi-dispatch #[library! [...]] "gtk_init" this
]

I'm using this as a placeholder for something that would get the currently running frame, right now you can get it via binding, so imagine something morally equivalent:

>> gtk-init: func [argc [integer!] argv [integer!]] [probe context-of 'argc]
>> gtk-init 10 20
make frame! [
    argc: 10
    argv: 20
]

But to paint the rough picture, the idea would be that some structures that are built and managed on the C side would instead live directly in the body, and be associated that way. The FRAME! very lightweight--size of a REBSER node only (2-pointers-in-size larger than a REBVAL, plus one pointer and change for overhead), and has a data pointer directly to the stack.

It seems to me that if FFI-dispatch did the frame decoding, what you'd have won't be much different than today in the invocations. However I think a big win here could be if a lot of the MAKE-ROUTINE part of the logic of doing the prep work could be Rebol code. If it needed to do some kind of precalculating it could even do that into a binary that could be passed along as a constant. For that matter it could do all precalculation so the call winds up looking like:

gtk-init: func [argc [integer!] argv [integer!]] [
    ffi-dispatch #{73CAD0...E5F9} this
]

I'll have to look more into it. But because I've only started thinking about this recently, it's not urgent. I just thought I'd mention the direction to you now in case you had any thoughts.