CiviCRM inconsisent behaviour on recurring payment for membership

Current code says 'don't process the membership part of a recurring contribution membership as we expect the payment to happen in a bit.

As Authorize.net was one of the first payment processors to support recurring membership with recurring contributions the code generalises Authorize.net behaviour to be normal for on-site-type payment processors. This is not the pattern that emerges for token-based processors (e.g IATS & eWay) and it makes more sense for the code to rely on what the payment processor 'tells it' than assumptions.

Direct payment processors have the opportunity to alter $params and I note that IATS sets $params['trxn_id'] after processing a contribution - this seems a valid approach to me and the form could 'listen' for that and processed the membership if the trxn_id has been set.

Note that none of the inbuilt payment processors touch this value ($params['contribution_status_id']) and IATS is the only extension that I'm aware of that does. Eway doesn't but I would change it so it does in order to take advantage of this

http://forum.civicrm.org/index.php/topic,13758.msg144432.html#msg144432