I have a semi-working implementation that I'll be committing to trunk in a bit...
I'm confused. Semi-working would seem to be orthoganal to keeping trunk in
a releasable state, but it depends on what you mean. But before you commit
a significant change, please first consider posting the patch, or simpler, please
consider a sandbox fork for iterative development? From the project bylaws;
When to Commit a Change
Ideas must be review-then-commit; patches can be commit-then-review. With a commit-then-review process, we trust that the developer doing the commit has a high degree of confidence in the change. Doubtful changes, new features, and large-scale overhauls need to be discussed before being committed to a repository. Any change that affects the semantics of arguments to configurable directives, significantly adds to the runtime size of the program, or changes the semantics of an existing API function must receive consensus approval on the mailing list before being committed.