kelson

That’s bad enough for those of us who want to make things more specific, but what about people who blog in another language? That ends up producing feeds with bad metadata.

I know it was a fight to get the feature back into WP 1.5, but without a UI to set it, it’s almost worse.

Adding a field on the Reading>Options page, under Character Encoding, should do the trick without causing too much clutter.

It’s still broken in WP 1.2.1, but fixed in CVS.

I’ve seen the PCUser plague as well, and seriously considered blocking on the UA string. (Fortunately, installing a slightly modified three strikes plugin has blocked the current run.) A search through my site’s logs for October for “PCUser” — nearly all were (attempted) posts from this scumbag.
Nearly all.
I did find three visits — all early last week — that looked like normal web use patterns: each came in from a Google search, two were single-page visits while the third looked around at a half dozen pages, and they hit all the associated scripts, images, stylesheets, etc. They were also all hits to other, non-WP areas of my site. So it looks like *someone* has that UA, but it’s very rare.
I’ll be renaming wp-comments-post.php to be a bit more proactive. I was going to suggest an option to randomly rename it as part of the install process, but realized that would be trivially defeated since the bots are obviously pre-harvesting the URLs (based on the presence of referrers in the hits). They could as easily harvest the script location as part of the process.
(As for recommending that people search the archives… what do you think FAQs are for? As long as it’s suggested politely, it saves everyone more time in the long run, including the person asking the question. Give a man a fish vs. teach a man to fish, as the old proverb goes.)

This is also an accessibility issue. When there is a primary language for a document (be it HTML, RSS, or anything else), it’s advisable to indicate that for the benefit of screen readers, search engines, aggregators, etc.
OK, so it’s an easy one-line addition to each of several files. But most people publishing with WP probably have never even read the RSS spec, probably don’t even know that this tag exists. They aren’t going to add it without a massive education campaign like the Web Standards Project or Mozilla evangelism projects. Even then, it’ll only be those comfortable with hacking PHP and/or XML. For many, the whole purpose of using a publishing tool like WordPress is so they don’t have to worry about coding!
Alternatively, a small, easy change can be made in the authoring tool that will make their feeds easier to index and thus easier to find. IMO it doesn’t even need a UI, as long as the language is stored somewhere. It would be one of those sensible defaults.
As for “bad or false” metadata — I don’t think anyone here is advocating that. If the feed contains multiple languages, it seems to me that would be the case for leaving out the tag.
The only reason I can see that this feature would not be easy to add is if WordPress does not know what language it is being used in. I have been assuming that, with the localization push, WP would have this stored somewhere. If not, please correct me.

s/required/recommended/
It may not be required, but it would certainly be useful, particularly for feed discovery, accessibility, etc. If WP already stores the (default) language somewhere, it should be easy to add the tag. If not…, well, it probably should.
As for multi-language blogs, the RSS spec states that <language> only applies to the channel element, not to individual items, so that would be a case where it would be better to leave the language tag out or to pick the more-frequently-used language (if there is one).

There is one circumstance in which “paged” pages do *not* change: monthly archives, once the month is over. For instance, I have two pages worth of posts for August 2003, and those are never going to change (barring typo corrections, extra comments, etc.)