i like the idea of easy sql selects locally. enables many interesting applications.

so it is a rpc client? or does it use p2p commands?

if it ONLY stores the unspent ouputs, how does it react to chain reorganisations?

It uses the bitcoin p2p protocol: setting up a connection using TCP 8333, sending version/verack messages and getting data using getblocks and so on.
(just like an original Satoshi client)

The standard data flow (no chain reorganisation) is as follows:

• New blocks are downloaded first (and pre-processed = extracting info from txs) into "Chain___" tables (block and transaction data) and there is an attempt to determine their block height. This is indicated on screen by the "Count:  xxx yyy blocks" which means: received xxx blocks from yyy in total.
• Any block more then 10 blocks deep in the chain gets pruned: tx outputs of each transaction (the new unspent outputs) are added to the "TxOutAvailable" table, tx inputs of each transaction cause their corresponding output deleted from the "TxOutAvailable". If that succeeds, the block is deleted from the chain list (the point of no return so to say)
  Status is indicated by "Pruned up to block: zzz", which will be always at least 10 less then "xxx"

If a chain reorganisation happens, the received block does not append to the end of the block chain but some blocks (mostly 1 or 2) deeper down the chain.
As BiRD maintains a chain list (and full block data) of the latest 10 blocks as explained above, it can remove the obsolete (orphaned) blocks and accept the new block instead.
Only if a chain reorganisation should occur more then 10 blocks deep, BiRD will not be able to cope that, but then there is probably something bigger going on (as in attack of the block chain).

I started developing this client about a year ago when the official client was version 0.3.24 something.
The reason being simple: after a few tries, I couldn't get to compile it on Windows, and I need(ed) some extra features which weren't available at that time:

• easy access to any balance, not just those bitcoin addresses of the client wallet;
• "raw" transaction interface.

Why do I need those features ?
Well, I'm working on a smart card that is able to sign bitcoin transactions with a setup similar to this: smartcard <-> GUI client <-> BiRD <-> Bitcoin Network
So that's my personal goal. In fact, the project is nearly ready for its first release (but I don't like vapourware, so I did not announce anything yet).
In short, the GUI client does the following:

• talks to the smartcard to get its bitcoin addresses
• asks via BiRD the open transactions
• shows these to the user in a friendly manner
• lets the user build a new transaction
• asks the smart card to sign it
• broadcasts via BiRD the transaction into the Bitcoin network

But I think many kind of applications (websites, even smartphone apps) can benefit from BiRD (being a much easier interface to the block chain), so I decided to make it open-source and available to everyone (it's EUPL).

congratulations! cool project.

it would be nice to use this as a backend for the Electrum server.  (currently, the Electrum server can use bitcoind+abe or libbitcoin)

This is quite interesting. Has there been additional progress on BiRD? Has there been any thought to implementing something like MongoDB?

Have you heard the news?
About the BIRD?

https://www.youtube.com/watch?feature=player_embedded&v=2WNrx2jq184