This Capabilities Types Suggestions category has gone very, very, stale…
@Ben very responsively created the “New Capability Types” Category on the Forum (now called “Capability Types Suggestions” in February 2015, but there has been less than a trivial amount of participation from SmartThings engineers. There are hundreds of user Views reported of the posts in this Category.
Meanwhile the official Capability Taxonomy has grown by only 2 or 3 items in the last year (well… somebody check more closely and let me know).
So … I can only conclude that:
(a) SmartThings believes that the Capability Taxonomy was created with all the items we will ever need, and considers the new “Suggestions” to be superfluous.
or (b) SmartThings has abandoned the maintenance of this quite clever, and even, brilliant portion of their fundamental architecture, in favor of the ease of use of ad hoc Attributes and Commands, even though the latter results in a hopelessly fractured device type library, filled with redundancies and inconsistencies. When appropriate new Capabilities are eventually introduced (if ever), dozens of Devices Types which used ad hoc Attributes will have to be manually updated to comply with each new definition; and also dozens of SmartApps which could have input() filters based on these new Capabilities.
and/or (c) SmartThings new architects have not been motivated to learn the full depth and power of the Capability Paradigm, and/or does not want to deal with the creative range of suggestions made in the Category (some of which are, IMHO, extremely relevant, and some have been submitted with good intentions but fall outside the design purpose of the paradigm).
Optimistically (or cynically?), I think SmartThings may be working on a major overhaul of the Capability Paradigm. This would not be atypical of SmartThings – i.e., instead of an incremental in-place fix (i.e., add a few new Capabilities even if they are not “perfect”), they are coming up with an entirely new model which introduces significantly more development effort and platform risk, not to mention the tremendous effort needed to rework existing Device Handler and SmartApp code.