To me, it seems more useful to focus on suitability of the solution (i.e.
Gruenke,Matt
domain, rather than making legalistic arguments based on precedent.
For instance, you could consider Boost.Thread and Boost.ASIO. They would've been useful as simple pthreads and sockets API wrappers, respectively. But they went further. Why? I'd like to think it's because this would've left out too many platforms with similar APIs, or with native APIs that offered better performance than going through a pthreads or sockets emulation layers.
My argument is part of the discussion: "Should Boost.Compute be based on the OpenCL C++ or OpenCL C layer?". My argument makes no sense when trying to answer "Should Boost.Compute support one or multiple backends?".