Specifically for the 96boards, the spec is a recommended view, but its not meant to be constraining, however it does allow one to then show a best practice, that others can adopt. That's where the RPB comes in to play, again to demonstrate and not restrict.
Sorry to jump in on this, since my horse in this race is pretty small...
That whole "best practice" point is REALLY important. But it's more nuanced than just "do it this way":
A. Vendors will do what they do, and they'll have their reasons. If the community offers them a "best practices" guideline, especially one that's easy to adopt (in full or in part), then hopefully they'll be less likely to stray.
B. If that best-practices document offers more than a one-size-fits-all recommendation, then so much the better. Again, it keeps necessary variants closer to the community than they might have been; a partial victory isn't a total loss.
C. (This is my main point.) When I see a document that says "best practices", then I understand that there's no binding requirement per se, and that it's likely that there will be deviations.
D. When that's the case, I'm more likely to produce code that's easily adapted to the various permutations of best-practices that I encounter, often with the blessing of my customer. Doubly so if those variations are predictable.
Otherwise, a customer will tell me to just "code to the requirement"---and that's all they'll pay for. Then my solution isn't likely to be as widely deployable, which cuts off opportunities to recycle that solution back to my point (A), even if the code becomes public.
I can't always code for every possibility. But, with a best-practices guideline that says "if you can do it X way, then do so; if you can't, but you can do Y, that's almost as good; else, for gods' sake don't do Z", I can better plan for where the changes might arise later.
Maybe I won't code the solution for everyone, but I'm likely to get a lot closer than I would have.
Just my $0.02.
b.g.