|There's more than one way to do things|
It has remained unapplied, because it is belived that it would cause increased (db) server load. (I can find no purticular reason for this belief, in fact, it should reduce the new-reply path by one getNode call, IIRC.)
Wow. You have a patch that will allow any number of users to request notifications for a node (by putting data into the database via a web page that will read hundreds of records from a database), and then it sends notifications to all of these users (by inserting a /msg record into the database for each such user -- unless you aren't using the current /msg system) and all with less work than is currently done (to send at most one message)? That is just amazing.
Of course, it isn't true.
In fact, your change would cause the entire list of people interested in a node to be read every time the node is displayed (and, with the current node cache, the list would have to be rewritten every time the node changed, including every time someone votes on it). So the increased load isn't just when people "subscribe" and when people reply, but every time a node is displayed. I don't know how much of an increase it is, but with a system that is (once again) out of DB server headroom, I am very reluctant to apply patches that cause the DB load to increase even a little.
And you should be careful about putting words into others' mouths. The increased server load is a small part of why I haven't applied that patch (I can't speak for why any other gods haven't, or if any have looked at it).
Then there is the issue of many people probably wanting to track a thread or a subthread rather than single nodes. Then there will be the requests for "which nodes am I currently tracking" which, with your design, would require scanning the entire node base.
Then there is the problem that it would change "/msg me when I get a reply" to be "/msg me if I get a reply to a node that I wrote while I had this setting turned on". And I'd rather avoid the use of "maintenance" nodes.
I think these problems are pretty good reasons for me not having put those patches high enough on my to-do list to get around to applying them yet.
The only plan I've heard that I consider viable at this point is: Do this external to PM (but please be very mindful of making efficient use of the server resources when you automate any use of PM). I suggested this a long time ago but I have yet to hear of anyone implementing it, so I don't feel particularly guilty for not having spent time trying to implement it inside of PM (such as by analyzing your patches, trying to come up with a better design, etc.).- tye