So my blocking concern is that APR has never shipped an unready, disabled by default feature. I don't mind not ready for prime time but we traditionally called such things alpha or beta releases. I am not worried about a specific platform, but about the wide range of unreviewed architectures.
The Solaris report seemed concerning. Many of my AIX observations were incorrect libtool flavor detection for DSO and subordinate test program invocation, but some weren't. (Can't test if mutex returns immediately.) I will know Tues if this is entirety a regression or anticipated exception. I'm afraid BEOS may already be abandoned. The comments about windows specifics were also concerning, but I have to change gears Sunday back into that world to start further review. In short, everything excluding tiimedlock mutexed seems long overdue. This new mutex feature extension seems hardly ready. I am -1 to have a default disabled feature, and -0 on releasing this code in its present state. Suspect it could use a couple months on the bench and a couple more active reviewers on a breadth of platforms to move it on to a 1.7/2.0 release. Just my thoughts, excepting your commit inverting a disable for an enable flag. I think we should finish 1.6 immediately upon reverting this feature on this branch, which means first forking to 1.7 to preserve it for another minor release in the not too distant future.
