Audio Nodes are subject to garbage collection delays. This effectively makes the API no-go for live performance situations. (I know you can't fix it either.)
Parameter change specifications contain either an analytic or a mutable form, but in practical implementations, both forms become desirable to implement efficient processing that can also begin at arbitrary times within the envelope. I cancelled my implementation of the API after discovering that the lack of detail in this section made for a fragile, confusing, trial-and-error situation to prevent discrepancies when comparing the results of the analytic form against the mutable one.
Rendering does not appear to have any automatic regression test available. Web Audio needs an Acid3-style test.
About the second point, that's not accurate. All audio processing in a conforming Web Audio implementation happens on a background thread reserved for audio processing, which does not need to wait for things happening on the main thread (including GC pauses.) In practice, Gecko's processing model uses message passing between the audio thread and the main Javascript thread. WebKit and Blink use locks to synchronize the two threads some of the times, but the locking is minimal and it should not have a huge impact on performance.
About the testing issue, the working group has started to work on it recently, and you can see the beginning of the work here: https://github.com/w3c/web-platform-tests/tree/master/webaud.... We're planning to integrate the regression tests from both Mozilla and WebKit into the test suite for the spec (http://mxr.mozilla.org/mozilla-central/source/content/media/... and http://trac.webkit.org/browser/trunk/LayoutTests/webaudio) into the test suite. And of course, contributions for more tests are always welcome.
The only solution is IMHO is to keep finding holes in the spec, driven by feedback from application developers, and plugging the holes.
I don't think a spec/standards committee can fix all of these issues, and like with OpenGL, I suspect, we'll need Web Audio 1.1/1.2/1.3/etc
We're approaching the stage where we'd like to go to "last call", so there's never been a better time to give us some feedback. Your experience of trying to implement the spec would be very valuable to us.
If you have any questions about getting involved in the group please contact me directly (I co-chair the WG) and I'll help you.