Riddle me this: How would you tell Zen Cart to "magically insert an order" for something that occurs externally via the payment gateway? And if you were to tell Zen Cart to just "guess" that the recurring payment hasn't been cancelled, then how would you "marry up" the two sides?
Or do you want Zen Cart to just completely ignore the "repeat" and just let the payment gateway do its multiple billing, without ever generating an order/invoice for the subsequents?
Those are the things that need more details.
It's a no-brainer to simply pass additional parameters to the payment gateway so that it knows to keep billing the customer. It's the proper generation of orders/invoices to match those repeat billings that's the "problem".
And since every storeowner has different ideas how it should work, and every payment gateway has varying levels of sophistication in terms of ability to tell the store that another payment has been collected, it's a huge task to write code that handles every possible scenario ... cuz as soon as we put out a "limited" module that only handles things "one way", we'll get a thousand people complaining that it's inadequate because it doesn't handle it "their way".
The secondary aspect is the need to write custom data schema and custom product-type requirements to manage all the possible combinations of repeats that are needed for any given product. (downpayment with or without X additional payments, "X" equal payments, "XX" amount every month/quarter/year, ending date if any, etc, etc, etc) And if something is supposed to happen inside Zen Cart (ie: renews membership access to a certain aspect of website, etc), how will Zen Cart know about that, especially if the payment gateway doesn't have a notification tool to tell the store about the completed renewal payment? What about the merchant who refuses to pay for the additional monthly fee charged by many gateways when recurring billing is added to their account?...should Zen Cart provide some sort of makeshift "simulated recurring billing" that emails the customer about their expiry and gives a link to bring them back to the store to re-buy by supplying their card data as part of a new purchase? (that'll require a bunch of specialized infrastructure too) ... and the list goes on.
Those are more things that need more details ;)
So, this is really another invitation to crowd-source the specs that would work for the broadest range of merchant requirements around the globe, so that the code could be written to suit those needs. If the people "wanting" it would explain the complete big picture of ALL they need it to do, that would shorten the amount of research required and allow the coders to write code to meet the requirements.
Until then it's probably gonna be just what it's always been: individual merchants write something bespoke for their individual needs, and rarely share it with the community.
Care to start the Features Wish List discussion to collect the broadest range of (highly-detailed) information on all the myriad aspects of what they would need?