It encapsulates symbol lookup, possibly searching multiple libraries for a function. But that's not all: by wrapping Ffidl callout into an auto-generated Tcl procedure, it provides additional argument types that are pre-processed and post-processed before and after callout.
ffix also included some commands to manage in-memory buffers, thus allowing you to use functions with deferred input/output. This relies on Roger E Critchlow's Ffidl 0.6 (stubsymbol), while the other parts of ffix may work with Ffidl 0.5
This initial release of ffix is highly experimental and subject to changes in the API. -- Anton Kovalenko
When adding things to the core, there is always a trade-off between adding the useful functionality and keeping the core relatively small (hmm) and maintainable. But Ffidl has a huge potential usability and is yet relatively small in size.
Why do I think that there is a huge potential usability in Ffidl? Here is an example: 3 days ago I was looking for ODBC->TCL binding that would support unicode SQL types. I considered adapting Tclodbc... but I've decided instead to make a low-level API calls with Ffidl and create a high-level interface with snit. Now I have a drop-in replacement for Tclodbc that works with unicode types; if I'll need some ODBC3-specific feature, it'll take only a few minutes to add it to my project.
There is a question: would anyone bother implementing Tclodbc as a binary extension, if Ffidl were in the core? Well, I can't say for anyone, and ODBC is not that simple; it's possible that someone would write Tclodbc even in that case. However, I'm sure that a lot of binary extensions existing today would never be binary, but pure-Tcl, if the pure Tcl contained Ffidl out-of-the-box.
For some extensions, implementing them in C is justified. However, a lot of extensions are mere replacements for the missing Ffidl: the only thing they do is forwarding script commands to the OS or some external library.
Lars H: Putting something in the core is always very sensitive, but presumably "package bundled with the core" (like threads or http) would serve just as well? From the look of the above, it also seems this package has some maturing to do (not necessarily improving, but proving stability) before either could be considered, though.