Alan - thanks for a great response. Google News requirements are bizarre. I would get around it with a sitemap but still the 4 digit unique ID requirement? Go figure that one... I guess five digit article ID minimum it is. I'll have to change the autonumber in all of my blogs...
Regarding the above, If all was equal, I am in total agreement. I think that SEwatch is the optimal. But I'm not sure all search engines will be equally kind to additional directories added into the URL. There is also increased issues to watch how the server handles adding directories that aren't really there (and you've pointed out a great use of excellent programming but you have to be on top of all these redirects!) There is also the issue (as below) with decreased legibility. I regularly find Searchengineland's articles at the top although I can't be sure that it's the URL or other factors which could easily be responsible. Let's go into the other aspects:
I noticed that URL shortening is much less attractive for the /12345/ suffix (searchenginejournal) versus the -12345 suffix (searchengineland). Look at what happens in Google (although not in IPB). The keywords will be far more visible for the latter rather than the former. I am guessing this is the case because most keywords are contained within the last "directory" that the script sees which is between the front slashes. As a result, the script (including Google) uses the first part of the URL and shows the keywords but not the ending which is omitted entirely (and is the numeric item ID).
SEland: www.seland. com/article-name-here......
SEwatch www.sewatch .com/art.....re/12345/
The flip side is this - it's so much easier for a server to parse the second version because it knows where to look for the article ID. It can skip having to read in e.g. 30 characters and go right to the front slash since it knows that the ID is following. With the SELand example, the server has to get to the end of the article and then go back several spaces until it encounters a dash and the can determine the proper article.
The same goes for having the numbers in the URL as in the stock IPB install as is here in this forum. No need for the server to go through the entire URL and any truncation of the URL by a user can STILL be read by the server if it has an option to find the article solely by article ID number. The negative is that people read left to right as do search engines. The numbers are a bit of an intrusion and also will appear in URLs and probably make for the least friendly for the eye.
I'm not sure how much of any of this matters. It would seem, though, that either /12345-subject-name/ or /12345/subject-name/ or /subject-name/12345/ would be optimal from a technical perspective, the key being a trade off of readability versus functionality. The searchengineland version seems to perform well but is the least optimized by the machine for both speed and reliability.