The way Q&A work has been done at Mensys has never been realy been different for the last 10 years since I have always done this.
We noticed. It has always been "late", and the end result has always had more problems than a user would expect. This was not unexpected in early releases, as everybody was learning. It is becoming more irritating because the record isn't getting any better. It is still "late" and there are still more problems than expected. Some of the problems are not really unexpected, but you (or somebody in the team) knew about more than one of them, before the beta was released. That should have stopped it, or you should heave gone back to what is known to work for the majority. I would also suggest that announcements of new public betas should not take place, until you have one, in hand, that works for your testers (obviously, you need more testers, to do Alpha testing), Then, the only changes that get made, would be to correct a found problem, then the beta test starts over again. When all of your testers agree that it works as expected, then you announce a public beta, and nothing changes unless a serious problem is found.
The fact that the wrong USB drivers got included, on the first download, demonstrates that somebody lost control of the product quality, and/or nobody did proper testing of the product before it was released. Announcing it, then delaying it, demonstrates that you do not have control over the product.
It seems that you need to have a list of machines that need to be tested, including newer and older laptops. Then, you need to know who can do testing for those machines (more than one, when possible - preferably an experienced user, and somebody who is not a techie), and be sure that they test specific parts that have been changed. In many cases, the test only needs to include changing a driver (like Dani), to be sure that it still works, after somebody changes something. Once all of the testers agree that something new works, it can be inserted as a candidate for the next beta, or GA. At that point, if somebody wants to change something, they (or you) need to make a business case for it, and the testing starts over. If it passes, it goes into the next release. If not, it goes back for repair, and the testing starts all over again. As soon as a product is deemed to be stable, it gets packaged as a beta, is tested by the testers, THEN you announce a new beta, or GA, and NOTHING changes. If somebody finds a problem, the process starts again.
Once a Public beta has been announced, the next Alpha cycle starts. Any new changes go into that, not into the current beta, which gets repaired only (nothing new), and eventually becomes the next GA, after found problems are repaired, and everybody (including the person who found a problem) agrees that it works as expected.
I am not saying that EVERYTHING needs to be fixed for any specific beta, or GA. You should be able to make an exception list, with known problems, and work arounds, when possible. From that information, a user can make a more intelligent decision about whether to participate, or not. Blindly falling into a problem that can disable a NIC (even in windows), without warning, is not going to impress many people. There will, of course, always be new hardware, or somebody will introduce a new program, that will surface problems that did not get caught, but they should be pretty rare.