dflemstr: Personally, I think writing a DS emulator would be alot harder right now. The PSP is well documented software wise and its been around for some time already. You can easily compile your own applications to test the emulator. We also have really good debuggers like PSPLink.
CC_machine: Yes, my plan is to have a working version out at the pandoras release day (with support for the applications which are working already through the library)
borgqueenx: No, you can't say that. Anyone who says its impossible is talking bullshit. At the same time, those who say it will work without any problems are also talking bullshit. From what I have done with the beagleboard I think its safe to say that it has the potential power to emulate a PSP at full speeds with most commercial games out there - I m not saying that this emulator will do one day. The pandora has enough ram to recompile the whole game on startup and only doing dynarec once the code modifies itself (if thats even possible with the original SDK)
Butterman: This will be an emulator. However, its split into 2 parts for easier debugging and development. The library is only a wrapper as you already mentioned, I'm post-editing the generated elf through the makefile so DMA is possible (using some dirty IPC to emulate the cached PSP memory). The library comes with the PSPSDK headers like pspgu.h which are calling the functions which are defined through *.S (assembler) files in the PSPSDK. The library implements these functions in *.cpp files. This means that if you compile a PSP sample code with the library, it will use the PSP memory addresses whenever possible (sometimes regions are reserved for special stuff in linux) and the samples code doesn't have to be touched a single time because only the real system calls are implemented.
The second part of this project is the real emulator which comes with a mips emulator, memory manager, file loader (bin and pbp for now - iso support coming soon) and the files as the library.
I do this because the system calls are well known but the Allegrex cpu doesn't have too much information (I use a mips32R2 instruction set as reference right now). I can test the samples and implement all systemcalls with debugging symbols in a high level languages. The mips emulator is also working already but it doesn't have many instructions implemented (no float instructions yet, as I said before). I can already run the cube sample through the emulator, but its still getting stuck in the crt0 code - however, the system calls are mapped correctly and I know that the problem must be in the low-level mips emulation because the sample works fine if its running in recompiled mode using the library.
conso: There is noxas pspplayer which is working extremly well from what I have heard. I only had a short look at its sourcecode though because it doesn't even work on my computer.