It'd be a minor nightmare to code. It would be a major nightmare either on server load to do all of the checking required each time the nodelet is displayed or a major nightmare in resources to be able to update all of the personal nodelets whenever a new node is posted.

In other words, it will never happen.

If one wants to track a list of threads for new replies, then the only scalable solution is for each user to keep their own list of threads-to-be-tracked and record the last time they checked. Then each user can infrequently fetch the list of new replies (since the last time they checked) and compare these replies' root node IDs against their list of threads (and update when they 'last checked').

If one wants to track other than just by root nodes, then the amount of complexity to do that efficiently goes up a great deal.

There might eventually be something similar to this done inside of the Monastery using a cron job. But it certainly won't end up in a nodelet (barring tons of work in caching).

And if one wants such a feature, the fastest way to get it is to implement it outside of the Monastery using existing Monastery features.

How about including the last modification date in the link and letting the browser do the rest? And if it is still too heavy for a nodelet than make it a separate node. This way what is left is only updating the thread last modification date at each write - but writes can be a bit expensive since they are not that frequent.