I'll took a look at it in more depth later to understand how he worked his code to get his results.
Below are some points I took into consideration while reviewing his work:
Why each MOD was created:
It appears that he designed his work to keep certain topics from being archived. Thus, the need to flag them.
Since I have never (so far) in the 5 years that I have been using Snitz have had a need to archive topics by batch, I wanted the ease of archiving them individually as well as unarchiving them individually (in the event that I archived something I wanted to bring back into a current status for discussion).
In that sense, the mindset for why the MODs were created is different.
His work deals with segregating individual topics from being batch processed as well as archiving/un-archiving single topics.
Mine doesn't deal with batch processing. It offers an alternative to it.
I do like the flagging approach. I see a need for it. I just don't do batch processing, so I had no need to include it in my work.
What db properties each MOD modified:
His work calls for an edit to the TOPICS table to drop the T_ARCHIVE_FLAG field and add it to the A_TOPICS table instead. He didn't include this as a dbs_ file in his download for some reason, but he did offer it in the link you provided.
I wanted to create a work that didn't alter any of the standard existing db fields, since that could mess up other MODs as well as exising code. Instead, mine has a new table that stores the old TOPIC_ID and the new un-archived TOPIC_ID.
What each MOD produces:
As far as getting to the topic information, the results are the same.
However, his work is able to
restore the original TOPIC_ID. My work gives a
new TOPIC_ID.
Personally, I like restoring the original TOPIC_ID better. If I had known at the time how to do it, I would have saved myself some time and done it that way. But I am happy with the workaround that I found. I don't see a need to change it since it still gets the user to the correct information.
Where each MOD is accessed from:
On the adminstrative side of things. His work focuses on archiving while browsing the forums and the topics, while my work focuses on working from the admin section (currently).
In admin_forums.asp his work functions like the current admin_forums.asp, so I don't see a difference there from what Snitz already offers, unless I am missing something.
In my admin_topics.asp, I incorporate each forum almost exactly as it is displayed in forum.asp (this is true for current and archived topics). This is something admin_forums.asp doesn't allow you to do.
General Summary:
The main differences I see currently are:
1) Mine doesn't work from forum.asp and topics.asp (yet)
2) His flags topics from being batch archived.
3) Mine wasn't intended for batch archiving.
4) His doesn't give you the individual topic selection from admin_forums.asp
5) Mine is gives individual topic selection from admin_forums.asp.
6) His restores the original TOPIC_ID.
7) Mine gives a new TOPIC_ID.
Where each MOD is in development:
It seems cripto9t's MOD hasn't been updated for nearly two years. I did a search for "Archive Flag" in both the Subject and the Message of the current and archived topics and found little about it. It would be cool if he would update it and package that dbs_ file with his download!

It looks like his was a really nice work!
My work is just in the alpha phase, and comments are welcome.
In the beta I plan on adding functionality like cripto9t did in forum.asp and topic.asp so that a person can access admin_topics.asp from the Admin Options on those pages.
I'll try to contact cripto9t about incorporating the flagging of current topics part of his work into my work. It appears that no change is necessary to the T_ARCHIVE_FLAG in the TOPICS table for this to work.
Thank you for your input!
Etymon
<