Use the STSADM operation 'databaserepair' to see if the site  is orphaned. If
so, use the same operation to remove the orphans.

I did not get a chance to use it though, as I found an obscure reference
to someone else's post about the problem.

It turns out that every now and then moss  2007 blows up when the GUI is
used for deleting  a LARGE site  collection.

By the time I got your reply I'd already performed a manual intervention
by going to the SiteMap table and removing the entry for the
/sites/research entry.

Specifically, I ran an SQL Query statement against the table under the
_Config database.

DELETE FROM SiteMap

WHERE Id = '<Insert long Alpha Numeric Site ID number here>'

All the problems went away. Obviously, should I run  into difficulty
when on production, then I'll try the other commands first.

MS really, really, really hates it when you do anything in SQL. They really
hate it. They hate it to the point of refusing support if they think that
caused it. SharePoint doesn't do any kind of referrential integrity checks, so
it's possible to remove things in SQL and cause some huge problems.

Always look at SQL as a very last resort.

But SQL edits are fun and enjoyable for everyone.

Okay, so I definitely agree with you that editing the database directly is
risky, but there are some things that you just have to do (in fact with WSS
v2 / SPS 03, MS released cute little additions to run  that were basically
just running stored procs for you with arguments rather than telling you to
go and run them yourself).

In this case I now know that we should delete  large site  collections
using the command line tools. Fortunately, this was my pre-production
test environment that I'm running in VMware ESX... So I just took a snap
shot and started running commands!