While I’m glad to see Glass finding some utility in the enterprise sector, if you want to expand far enough to reach consumers and hobbyist developers again, you’re going to have to address what happened under your predecessor in the Explorer program. While Google’s public messaging has consistently put a positive spin on it, people who actually had Glass units, especially people who tried to develop for them, hold a lot of ill will.
I would caution very strongly against releasing a closed-source version of Glass to the public, and if you do release a closed-source Glass, that needs to be very clear in pre-purchase marketing materials. Glass XE gave the false impression that it was open source, by being based on Android and having a source code download page that was unclear about what was covered (just the kernel). Being closed source turned what should have been a one-line fix (I eventually got the filename and line number from debug info, it really is one line) into a political campaign and an enormous amount of ill will. (https://code.google.com/archive/p/google-glass-api/issues/484)
Put some thought into the auto-updater. On Glass XE, updates could not be refused or even postponed, and this ruined peoples’ demos and greatly increased the damage caused by bad updates.
If you haven’t rearchitected the Timeline API, you need to find a way for users to take photos without them being sent to Google’s servers. And don’t let the CSRs distribute non-working instructions for preventing photos from being sent to Google’s servers, this time. Or at least censor the ADB log so that people don’t notice. Silently adding a clause to the terms of service did not make it okay, and while the press didn’t pick up on it the first time around, they might on the second. (https://stackoverflow.com/questions/20644764/prevent-google-glass-from-auto-uploading-photos)