Social tools' namespaces
Please do not alter the reserved range 500-599. It was duly registered by prior agreement and the changes you point to would alter it. You cannot act alone in this matter and disrupt the work of others. I recommend you speak to someone in authority. This is a clear conflict, and it arose because you failed to observe the rules in the first place.
The "prior agreement" was based on the assumption that no extensions used that range, which as it turns out was incorrect. 500 was already in use by the extension before that "agreement" between three people occurred. I've checked Wikia's repository and it was indeed using namespace 500, before your attempt to "reserve" the range. This is not a "future" extension, it's a preexisting extension that has been cleaned up and added to the official Wikimedia repo.
The de-facto "prior agreement" was 0-99 reserved for MediaWiki internal namespaces (of which 0-15 are currently in use) and site-specific namespaces on 100+ since at least 2004 (MW 1.04 was limited to one-byte namespace numbers). In the half-dozen years which followed, many wikis were deployed with site-specific namespaces just above the internal ones or starting at 100+ like the instructions told the site admins to do.
Unless every wiki which deployed "by the book" using 100+ as site-specific is now expected to renumber all of its custom namespaces to some other range (something which we do not have automated tools to do, short of raw SQL UPDATE commands, as a proper namespace editor never did make it into MW 1.7+ core code) there should be no "reservations" of namespaces in this range to extensions. Quite simply, the designation of 100+ as the site-specific range pre-dates the changes to extensions like DPLforum to hard-code them to namespaces (there was nothing special about 110 or any other namespace number in the original 2005-06 implementation of DPLforum, this is a recent addition breaking existing sites).
If you want to "reserve" some block, use one which hasn't been assigned to site-specific namespaces since at least 2004, please.
If those people want to install an extension that uses namespace numberss that conflict with their wiki's existing namespaces, they can configure or modify the extension locally so it uses different namespace numbers on their wiki. But changing it upstream would adversely affect way more users.
The only namespace numbers that can really be considered "reserved" are those that are already in use on a given wiki.
The issue with DPLforum is that it was *not* hard-coded to any one specific namespace before July 2011; furthermore, once a hard-coded namespace was added, the one chosen was right in the middle of the most-used section for site-specific namespaces (by 2003 convention, 16-99 are for core MediaWiki expansion, 100-254 are free for site-specific use).
Some of us have had DPLforum deployed on high-traffic sites since 2006 (it was developed by user:Algorithm for Uncyclopedia in late 2005) and are now seeing configurations break because this hard-coded 110: is not the Forum: space on the wiki (prior DPLforum versions were manually configurable to any site-specific namespace) and in a few cases is already, predictably, being used for something else because that's where we've been told since 2003 to put site-specific namespaces, 100+
Upgrade DPLforum, watch wiki break in some manner because something was hardcoded after the fact (July 2011) into a space which should never have been used in this manner (the 100+ range allocated in documentation as site-specific, a convention which was in place about eight years prior).
If anything, extensions should not be hard-coding namespace numbers on the blind presumption that they aren't already in local use. At a minimum, there should be some means to override the namespace selection, either to point to a vacant namespace or to match a namespace already configured by the site for use with a prior version of the same extension.
The 2003 allocation of 100+ to be site-specific namespaces predates the after-the-fact 2011 hard-coding of 110: as DPLforum.
Using the extension default namespaces as a space where anyone can edit, claim any existing site-specific namespace as suddenly now belonging to one extension, then complain that it's somehow the fault of the system administrators of existing sites already using that namespace when things break is not the answer. Extension writers have to realise that their code has to be installable on sites where any given namespace, especially the 100+ site-specific area, is likely already in use and stop hard-coding namespace numbers in a non user-configurable manner.
Even the painfully-obvious "well known port" allocations in the TCP/IP world are presumed potentially in use (that's why you can put "Listen 8080" in Apache's httpd.conf if :80's already in use by another web server on your machine...) so why encourage the less flexible approach of hard-coding namespaces with no easy reconfiguration mechanism here?
