@Zahlen and @Fry thanks for taking the time to read the spec. and comment.
I had thought about "events" but am worried it will complicate the design also I think that the functionality you are wanting can be achieved without too much coding effort. Consider this (taken from the Dormant Funds Transfer use case):
:loop
get tx at after @timestamp and store in @txid
if @txid is zero finish
get timestamp for @txid and store in @tx_time
get tx type for @txid and store in @tx_info
if @tx_info != @am_type_subtype goto skip
So although the basic rule is that for the "event to run" a tx is sent to the AT with enough fees to pay for execution (unless it is in hibernation) the API functions will make it easy enough for the AT to determine what kind of tx has arrived and therefore what to do about it (you could create a bunch of subroutines which are called according to the @am_type_subtype or according to data in an AM, etc.).
Understand also that the hibernation idea is simply for an AT to be able to "save wasted cycles" as even if execution is being paid for there is no point in it just checking the block height and stopping.
In regards to "subleq" I thought it was doing what I had read but if it isn't then don't worry James - it can easily be fixed up.
