At the moment, its an experiment in native interface design.  The aim is a stream-lined FFI+ffi-compiler combo, with some hard-coded conventions to make it easier to implement common patterns when writing extensions, whilst avoiding the "gigantic-ball-of-mud" that is the ruby C api.  But, XNI does not try to do everything - since you don't get access to Ruby VM internals, you wouldn't use it for e.g. implementing a new data structure.

This is Jeremy's hitimes gem converted to use FFI+ffi-compiler:

https://github.com/wmeissner/hitimes/commit/b226af0498127a9e25f002b01db9230f68f93f7b

and converted to use XNI:

https://github.com/wmeissner/hitimes/commit/9252959cebc6678a969ba672438ba4b11ff98ef5

The XNI one has a bit less ruby boilerplate (XNI has the concept of a DataObject, which can have instance methods that automagically pass in 'self' to native methods).  On the other hand, XNI excises a few FFI concepts - there is no Struct that you can wrap around existing native memory, nor MemoryPointer for generic native memory allocations.

(as to why I used hitimes - its a fairly nicely written cext, it doesn't do anything super-complicated, but would be hard to implement in pure FFI due to the data structures and API calls it needs).

That's a really good question - "when you're unhappy with FFI+ffi-compiler" would be the pithy answer.  FFI isn't going away, so if people are happy with it, then I encourage them to keep using it.  At this point, FFI is stable and works.  On the other hand, if you're writing a gem from scratch, and you're going to end up writing a bunch of ruby boilerplate around a raw FFI api, and you'll need to use ffi-compiler to compile some native shims, then XNI might be worth a look.  At least once it is a bit more stable.

It will always utilize a ffi-like way of interfacing between the ruby VM and the native code (that is part of the design), but it won't always use the FFI gem.  There is a native backend for JRuby-1.7+, and I am currently working on a native CRuby backend.  There could also be a native backend for Topaz that uses ctypes (or whatever the RPython equivalent is).