I recall when you were applying for CVS access that we recommended that you take over aggregator2 and then commit your code to it, making it a total rewrite of an abandoned module.
umm... why not just delete aggregator2 from the repository?
If this was done, then we would have one less module in this whole confusing area of aggregators.
I didn't use aggregator2 for a number of reasons, from critical to trivial : 1. When disabling a module in 4.7, the database retains that the module was installed to prevent the module's re-installation and to which update hook it ran AFAIK. This would effectively mean that any previous aggregator2 users wouldn't even be able to install the new aggregator2 module (install script wouldn't run!), and that my own update hooks would clash with the old aggregator2's update hooks! Not something I wanted to get myself into! 2. I named the tables <module_name>_item and <module_name>_feed. if I took over aggregator2 that would have meant their names would be exactly like those of aggregator2's table names, and then I'd have a new headache of either changing table names for the sole reason of coping with aggregator2, or risk duplicate table names, just something I didn't want to get myself into. 3. Didn't want to associate the new module implementation with the many forum topics on aggregator2. 4. I didn't want to create a mix up for old aggregator2 users.
On a related note, the best way forward on aggregators is to make them componentized using a defined API. Then people can write plugins to the API, or pick and choose from what is available.
My module does contain a developer's API. It's relatively trivial to add aggregation for any XML format, standard or not.