Here's one attempt at approaching the question of features and veto-ability. This is of course just my understanding^H^H^H^H^H^H^Hopinion. (Purposefully omitted: APR's LDAP feature had one user -- httpd -- and that one user now has the necessary code, even if not all the build bits are working yet.)
The presence of most features in APR is highly subjective. I.e., there's no technical requirement for APR that says it must or must not have the LDAP or memcached or various other features. Whether or not it is present is not veto-able. The group of developers must collectively agree on the feature set. The manner in which an APR feature is implemented has a handful of technical characteristics which should be met. Incompatibility with the basic technical characteristics is veto-able. Providing a feature which uses a different memory management mechanism or different kind of programming interface or a mixture of APR and non-APR programming interfaces are examples of technical characteristics which are objectively incorrect. APR versioning rules place specific restrictions w.r.t. version boundaries on removals of features which don't meet requirements or additions of features which do. Breaking any of the versioning rules while adding or removing features is veto-able. LDAP specifically: Deficiencies in the LDAP interface were identified and not addressed over a large period of time. The group of developers sharing an opinion made clear the required technical corrections which must be made in order for the LDAP feature could remain for APR 2.0. In fact this was a compromise position, compared with the more extreme and well supported position of removing it entirely instead of fixing it. No APR developer besides Graham was aware of any progress on correcting the deficiencies over that time. The presence of LDAP in trunk without correction was veto-able. The removal of LDAP in trunk was not veto-able, as it merely was the default resolution to satisifying the technical objections expressed previously. Importantly, removing it from trunk didn't prevent the deficiencies from being corrected. (But we can't go down this path far without consideration of httpd actions, since httpd is the one identified user.)
