Different solutions appeal to different mindsets, so although this collection tool does not appeal to me, I do not mean to dismiss it. In case it's of any interest though, here's why I would not use such a tool: I believe that the task is just one instance of a more general problem that already has adequate solutions.
What makes it hard to find what you want? I would imagine it must be either (a) lack of adequate descriptors or (b) inadequate search features. You say you have tried using notes files, but case (b) can be handled just by using a plain text file (and of course any PIM that uses them). Case (a) would apply to any system in which you haven't properly described the macro, but with a plain text file you have instant access to editing at the time of creation and at any time thereafter (manually or via a macro), and, failing all else, you can run your eye over the whole page!
Could the problem perhaps be that your attention is already divided between "The forums' bookmarking tool, Safari's bookmarks, notes files"? If so, adding another tool will just give you more pause to think when saving data ("Ah, now it's this kind of data, so I need to use, umm, this solution" versus "I can add as text to a note, along with most other data").
I am making a case for using fewer, more generalised solutions for as many tasks as possible rather than multiplying solutions.
All you need to save is the page title and the URL. Since there are many ways to do that, from any browser, why extend the problem space and why reinvent the wheel?
There is probably no need to download a macro other than as insurance against this forum suddenly disappearing, but if you do so, I admit that some extra complexity enters a system based on notes: you will want to way to uniquely identify that macro from a reference in the note. However, that is an implementation detail since that could be handled in many ways.
How is that superior to using plain text? You can access text files with any tool you have to hand, they don't take up much disk space, they are transportable to any other system or user, and they aren't as vulnerable to total data loss as a binary database. Although the SWLite site assures us that "SQLite databases are remarkably rebust" (sic! I hope that wasn't cause by database corruption 
), it goes on to mention possible dangers before documenting its recovery API. [1] That's assuming that no backup is available, of course. To try to fix corrupt text files, you just need a text editor.