I understand, and I want that myself as I mentioned before. But this is also the reason why I implemented the old methods, as I will outline below.
You see, the process of developing a new Glare node would probably start by elaborate discussions on what Glare methods to implement, what the user experience will be, which methods are computationally feasible, and numerous other considerations. Those discussions and investigations would take a long time because users like yourself care deeply about the new Glare and would like to get the design perfect and solid. So it will not be as easy as choosing some state of the art Glare methods and implement them.
In the context of the current real time compositor project, where we are aiming for a v3.5 release in weeks, there just isn’t the space and time to do the aforementioned process properly. So it is clear to me that we need get the real time compositor in a good state first in order to spend as much time as we need on developing the compositing workflow of the future.
Furthermore, deprecating the old Glare is an unclear goal. It is unclear if it should be replaced, augmented, improved, or just left as is. And this is subject to further discussions as well. Whatever the decision, implementing the old glare seems inevitable and not doing it now would leave the real time compositor in an incomplete state.
While the real time compositor project on the surface seems like a project to get a fast GPU accelerated compositor, to me, perhaps more importantly, it is a project to get the compositor in a better shape maintainability-wise. All the old convoluted code is now—to the best of my abilities—revers engineered, organized, and documented to ease future development. So this is just a slow start for the journey of creating the compositor of the future, so ride along and bear with me. 