Is your code online?
Also, I didn't know that getters add more overhead than just a property slot. I'll research this.
I don't understand your criticism of `toArray()` because to me it's the best it can be. To explain: `toArray()` returns a cached array of the unpacked bits, unless a bit has been changed, then it lazily recomputes it. So that's pretty much as good as it can get. All the methods that use `toArray()` require an iteration over the bits, so the alternative to a call to `toArray()` would be to inline its code into every caller. Two reasons I didn't do that were DRY and because 1 more call in the stack won't have a huge overhead, IMHO. Still, more testing is required to know more perf details.
A possible optimization is factoring out the cache check from `toArray` and inlining that check into each method calling `toArray`, but that really only saves on a method call, so to me, it's negligible.
The design reason I've done things the way I did was because the aim of this class was convenience, simple code and good performance. I didn't factor it to be about absolute best performance. I think, if we're going for absolute best performance, an implementation in wasm or asm.js would work better, and I'm not interested in doing that right now.
So that's my point of view and I don't understand your criticism of `toArray()`. What am I missing in this perspective and what ideas do you have to create improvements?