I'm not really sure what context you're talking about. The "standard" use-case for Bitcoin is address-to-address transactions requiring the 20-byte hash of the public key of the recipient. This is what Satoshi referenced in his paper when talking about the future and lightweight clients. If you don't have at least this much information, you're not going to be using
standard scripts to send money without the whole blockchain. If this isn't acceptable, you shouldn't be using something like FirstBits in the first place (which, btw, I don't know for sure, but I'm assuming it shortens a BTC address by only keeping the first X bits of the recip address)
If you want to go outside the box and use something else, you could make this work with non-standard transactions: I believe you could use OP_LSHIFT/OP_RSHIFT in the TxOut script if all you have is the first few bits (I'm pretty sure this works) -- i.e. create the script to check only the first X bits of the publickey hash match the data in the TxOut script . Something like
OP_DUP
OP_HASH160
100
OP_LSHIFT
<Right60BitsOfRecipAddressWith100ZeroBitsAtEnd>
OP_EQUALVERIFY
OP_CHECKSIG
If you're asking about the necessity of future BTC protocols to support not holding the whole blockchain,
I would argue that it is critical. Any degree of success in BTC will lead to blockchain files way too big for users' computers, and it's even currently too big now for smartphones--which are also critical to the BTC success. I think we'd be burning a huge bridge if we allowed "standard" to include any procedure requiring the entire blockchain to operate.
EDIT: I just notices OP_LSHIFT and OP_RSHIFT are disabled, so the above script wouldn't work