I don't think the transferable bonds you described are realizable with the limited validation script currently in place. You have come to a different conclusion (that bonds can be implemented right away!), seemingly because of a subtle word-mincing mistake.
The bond, being an asset like any other, is transferable - if you get tired of receiving the repayments you can sell the bond to somebody else.
This output tracks the current owner of the bond. The owner receives the repayments and any accrued interest. Of course a newly issued bond is special, it starts out being owned by the issuer.
If the bond owner wishes to sell the bond, a sale message is broadcast on the exchange p2p network:
....
By scanning the block chain for payments to the current owner of the bond, and checking them against the repayment schedule, the software can automatically calculate which bonds are delinquent and which are mature. Issuers of delinquent bonds would show up in the UI as in debt until sufficient sums were paid to the owners pubkey.
The
issuer creates a bond, and is the first person to own it. The
owner of a bond is stateful (time-dependent) since ownership changes after the issuer initially sells the bond, and changes again each time it's traded on a secondary market.
There is one weak point here: you have to trust that the owner of a correctly-attributed bond key will actually construct a valid (protocol wise) bond transaction that transfers control to the owner_pubkey you requested. Given that you're also trusting this person to repay the bond, this is not necessarily a big deal, but it'd be nice to require it.
You have to trust the
issuer of a bond to repay it, but you should not have to trust the previous (or any other)
owner in any capacity. There are two ways to read your statement here:
1) The "owner of a correctly-attributed bond key" means the
issuer. You trust the issuer to repay the bond, so you also trust the issuer to authorize every ownership-transferring transaction - not just the initial transfer from [issuer]->[owner2], but also from [owner2]->[owner3] must be signed by the issuer as well. I don't think you intended for the issuer to be online/in-the-loop for every transfer. The main reason it's unsatisfactory is that the issuer could exercise influence by refusing or delaying to sign later transactions.
2) The "owner of a correctly-attributed bond key" means the previous the owner. The previous owner signs a transaction transferring the bond over to a new owner. Bonds may be traded many times on secondary markets, without the issuer's intervention. But now the previous owner is not the person you trust to repay the bond, it's just someone you have an ephemeral interaction with. So this weak point is a bigger deal than you suggested.
The problem begins with the restriction you already pointed out, which is that the script can not enforce a relation between the inputs and the outputs.
The second problem is that script cannot contain signatures over anything other than transactions, and only limited forms at that. So you cannot have numeric assertions in outputs because you have no way to verify the inputs are legitimate.
I don't think there is a simple way of expressing this constraint without storing additional state. Here's the easiest way I can think of to create an 'overlay currency', a quantity that can be issued like a bond and where the conservation rule is explicitly validated by blockchain miners.
OP_BOND
// valid in scriptpubkey only (yes this interferes with pruning)
Miners would need to keep an additional table to store the set of active bond IDs. The first time a hash-of-bond-message appears, it's treated as the Issuance, and added to the set. In all subsequent transactions, the rule is that the sum of the OP_BOND quantities (for a given bond-hash) in the scriptpubkeys must match the sum of the quantities in the inputs. 
Each party's action may be instantly validated, but who goes first?
