Standard issue tags used in Drupal core should be documented.

Great write-up.

Do we need a consistent policy about capitalization? At the moment sometimes we have "needs..." or "Needs..." and "Performance" but "accessibility".

1. Fixed the HTML markup on that page. Whoever invalidly intermixed definition list terms and descriptions into a UL structure, please read the HTML spec about definition lists.
2. Fixed capitalization of issue tags. I know that some of the tags are improperly capitalized on d.o, but that doesn't matter for those links, since Taxonomy module matches case-insensitive.
3. Fixed encoding of URLs.
4. Added API clean-up tag.

This looks done to me. Further tags may naturally be added over time.

Thanks for the kick-starting it!

ugh. It definitely does not make sense to document topical tags.

The tags that were on the page previously are all "meta" tags or have structural/organizational meaning.

Tags like jQuery, JavaScript, CSS, DrupalWTF, PHP 5.3, PostgreSQL, Token, Libraries, or Views are pure categorization into topics where applicable and do not have any special meaning. We should not document them.

Out of those that have been added to the page now, only the following may be considered:

- Coding Standards: Implies that community-wide consensus is required for the issue to be fixed. More consensus than for other issues.

- [D7] Upgrade path: Debatable. There's no special workflow bound to these. The "official" tag merely helps to get an impression of what's still not working. Normally, the tag should be simply "Upgrade path" + appropriately assigned version. Should ideally be renamed administratively.

There are also multiple and duplicate tags for other topics. But that does not mean that they are in any way official or have any special meaning.

By including tags in this list that do not have any special meaning, that page will quickly and infinitely grow to something that's a) no longer useful, b) unmaintainable, and c) anything but official.

The tags that have been added now vaporize the originally clean and mean list of special issue tags, since they provide irrelevant information in between highly interesting information.

Standardizing on one tag among duplicates is a completely different task and goal. It's an ongoing and never-ending site moderation job. Normally, one would install and use a module that adds synonym collapsing functionality to Taxonomy module (last time I checked there were multiple modules for this), so one does not have to update all nodes manually, but instead, duplicate terms can be merged automatically into the primary term as synonyms.

Can we remove those topical tags from the page again? (including or excluding the two in #8)

I've the impression that you'd like to keep some of the topic tags and perhaps even advance on them. That's probably fine, when done on a separate page. Thus, I'd recommend to split into two pages:

1. Special issue tags for Drupal core
2. Topical issue tags for Drupal core

The former listing most of the tags currently contained on the page -- tags that have a special meaning and may imply a certain workflow. These are indeed "official" and standardized, and do not change often.

The latter listing tags that have been widely adopted to steer and channel interest and contributions -- not having any special meaning.

Issue tags with special meaning:

• API addition: Enhances a current API, possibly backportable.
• API change: Changes a current API, not backportable (unless a critical bug).
• API clean-up: Rewrites a current API, not necessarily implying an API change. Top issue tag during "Code Slush" release cycle phase.
• Coding standards: Requires broad community agreement.
• Upgrade path: Needs to be resolved before next major release.
• Needs *: (As the name suggests)
• Performance: Requires benchmarks, platform tests, etc. More of a topic tag, but Performance is problematic in Drupal.
• Security: Requires Security Team review.
• String freeze: Needs to be resolved before string freeze of next major release.

All others should be topical tags. I'll iterate over them in a separate follow-up.

Topical tags from the current page:

Accessibility, drupal.org upgrade, Documentation, DX, Favorite-of-Dries, Novice, Quick fix, Usability

Topical tags from list in #11 mapping to a D8 core initiative:

html5, D8MI, cmi, wscci

Noteworthy topical, self-explanatory tags:

Update manager, JavaScript, RDF, CSS, PostgreSQL, MySQL, GHOP, GSOC, cron, Ajax

Non-obvious noteworthy topical tags:

- DrupalWTF: As previously documented, strange design or behavior.
- DX: Enhances experience for developers who want to code against an API.
- i18n / i18n sprint: Improves an aspect pertaining to internationalization (i18n), localization (l10n), or translation.
- Translatable fields: Fixes or improves translatable fields support. Needed by language system maintainers to coordinate efforts, especially with regard to moving http://drupal.org/project/entity_translation into core.
- IA: Improves Information Architecture.
- RTL: Right-To-Left language improvements.
- DIE: Attempts to get rid of stone-age code or functionality in core.
- Regression: Fixes a regression to earlier releases. [Might make sense to list this is a special tag]

How is "DX" different from "API clean-up" ?

They are similar but not the same. DX attempts to improve something for developers. API clean-up rather "fixes" something for consistency, performance, modularization, flexibility, third-party integration, etc. Not necessarily improving DX, but of course, that should ideally be the case ;)

the "Topical issue tags" apply to contrib as well as core, they should probably go on a page labeled "General-Purpose Issue tags (not specific to any particular project)"

The same applies to many of the special issue tags. Especially with regard to all "Needs *" tags. I'd suggest to simply remove the "for Drupal core" suffix from the handbook page titles, and perhaps merely state in a short intro sentence that their primary usage is in core, but some contrib projects use them, too.

Alright, as a last step, I've clarified some of the tag descriptions on http://drupal.org/node/1207020

You removed some explanations for why the tags are "special". Going to restore those now.