I'd like to thank mr. Tekkenlord for his most insightful comments, but would like to provide a more informative answer myself.
Here are some answers to Luigi's questions (I assume that is your first name, yes?):
1. The hardest things to code for CD-i Emulator were and still are the emulations of the undocumented hardware that controls the CD and audio interface and the MPEG hardware. The public API's of these things are well-specified in the Green Book, but the actual hardware that provides the functionality is not documented anywhere that I've been able to find. And I looked pretty hard...
So it had to be done by reverse-engineering the ROM drivers and watching the I/O generated by API traces. This work was somewhere between doubled and tripled by the fact that there are several generations of these interface chips, sometimes with radically different interfaces.
The video hardware is almost documented (and in the case of one chip, the VDSC, actually IS documented) and the emulation of this part of the hardware was also made much easier because the Green Book API for it pretty much matches the actual hardware (it specifies the memory formats of images and control tables in details; the only undocumented part is how the hardware knows where to find this data in memory).
The emulation for things like pointing devices, NVRAM and timers is almost trivial compared to the above.
Initially I had some trouble getting my 68070 emulation fast enough (it is entirely coded in mostly portable C++) but those troubles are long over, not in the least because the PC's have been getting steadily faster
2. The CD-i File Player would be able to extract any data (audio, video) stored on disc in a "standard" (that is, Green Book specified) format. The Green Book allows application-specific coding, e.g. custom run-length encoding, compiled sprites, etc and these cannot be extracted without full emulation. For that I would like to include some support in a future version of CD-i Emulator.
3. The basic motivation behind CD-i Emulator was that I didn't want to lose my CD-i title collection (part of which I programmed myself or contributed to significantly) because of aging hardware. When I started this work around 1997 the "demise" of CD-i was still quite fresh and it seemed quite urgent to get things going while there was still functioning hardware around. Of course, it now seems that the hardware is going to last much longer then one might expect from a system abandoned more then ten years ago.
4. There has been some development since the last public release in 2005, in particular on the front of development support and MPEG emulation. It has been going very slow, however, lately mostly because we've just had our second child last week (a beautiful girl). But emulation work like this is agonizingly boring until you get something actually working (just a lot of staring at traces and disassemblies, trying something, followed by more staring; see point 1). And then you need to root out bugs which means more tracing and more staring
One thing I would like to achieve with the CD-i File Player is to get some visible development work out there, but it hasn't borne fruits yet. It would be free (no payments) and probably use some form of open source.
I hope this answers most of your questions?