[CarCdr]

You have the basics figured out imo. I did something quite similar for an issue tracking forum on our site.

Add columns to the thread table or add new table(s)?

It is easier to add columns to the thread table. The two reasons it is easier:

a) You do not had to add PHP code to the various scripts that delete threads to delete your table rows.

b) You do not need to add JOIN code to the various places that retrieve threads.

The cost is storage. You are adding N bytes to every thread table row. In a properly normalized database, one would never add columns to every row when it is data required only by a small percentage of rows, but it depends on the site (size of thread table). In your case, if you are adding only a few percent of storage, then I would go with adding columns. If you are adding 30% increase in storage, well, that gets a bit more worrisome.

What about searching/sorting?

I imagine you will want to beef up the search form, as well as the "Display Options" of forumdisplay -- the script that displays threadbits.

When is special entry being performed?

If I understand correctly, your scripts knows when it is entering a special thread based on a flag that is associated with a forum. No problem. You can modify newthread.php to run your code. But, you have to consider edits of the post as well (editpost.php) and maybe the thread edit code (postings.php).

Modularize your changes!

It is a far better hack if you put all of the code into a separate include(s) so that modifications to the base vBulletin code amounts to nothing more than a series of calls to functions. If the main include were "my_music_review.php", then everywhere you need the code you would have the following somewhere near the top of the vBulletin script you need to modify:

if (this is a music review forum) {
     require_once('./includes/my_music_review.php');
     do other setup stuff;
}