The biggest problem is that the software as originally implemented was developed not by the BSA for all units, but by an individual for their unit. They expanded it from a pack application to a troop application. They opened it up to other units, and eventually the BSA bought it. It was never architected to expand to handle enterprise-level demands. That’s not an excuse, per se, just an acknowledgment of the role that development history played in the evolution to where we are now. I wish the BSA had fixed some of these types of issues (permissions! calendar!) before they released it to the world at large. Now that it’s in the wild, though, the question becomes whether to create a new problem to solve an existing one (e.g. intentionally expose all of the adults’ PII to anyone looking in order to make it harder to accidentally expose the youths’ PII), or to take the time to get the solution right instead of sprinting to the next buggy implementation.
I do disagree that the BSA believes that there is less of an issue with the youth’s PII being exposed, though. In fact, the adults’ PII is just as exposed when they accept the connection (although someone else pointed out that the information at least was exposed as soon as the connection was created). Anyone with the right (wrong?) permission sets in the unit can then see the adults’ PII. Like everything else relies on the volunteers to vet the data, and not to peek through our neighbors’ windows. It’s a less than adequate approach, I agree.
Adding search by email address was a big improvement, and is the BSA’s stopgap, as far as I can tell, while they rewrite a large portion of the back end structure to migrate what was a reasonable solution for small numbers of people to more of what they need for this large and diverse a group of users.
I don’t agree with this. I doubt even one of the parents in my unit would agree that they consented to someone from another unit viewing their PII, even in the ostensible interests of protecting the youth’s PII. Most of them would have to get an explanation about why anyone other than someone from our unit (even database admins, registrar, etc) would see their PII. I think most if not all would agree that they submitted it so it could be associated with their scout.
I’ve always thought that live search result guessing was a waste. It looks cool if you’ve got flops to waste I suppose, but I’d rather that they implement a fast, accurate search algorithm, return the results in a timely fashion, and let me sort out what the right answer is if the algorithm can’t identify a unique answer. If I can wait for a scout to mumble his way through the Outdoor Code, I can wait for a search to return. 
I agree that we need more data exposed to make it clear we’re offering the connection to the right adult, but it has to be a limited subset.
I agree that would be more helpful, but still not sufficient to eliminate all issues. Honestly, though, it seems like the right solution if we’re going to use partial email as a verification tag is actually to reimplement the search algorithm, or at least the partial indexing, so searching by email works efficiently. We know that has to be unique, per the way Scoutbook appears to vet the new account creation.
I’m not sure logically why one would associate a non-leader adult with a unit (in a database sense), except in relation to their youth. The only relationship a non-leader adult has with a unit is via their scout. It seems like adding a relationship between a non-leader adult and the unit would just be an extra piece of data vulnerable to corruption and requiring integrity checks. It just seems like one more relationship between records to manage, especially if they have youth in more than one unit at a time. Maybe this is already done behind the scenes once the adult is connected to the scout, and they automatically inherit the unit from their scout’s record?
I think at the root of it all, we’re violently agreeing that the software needs work, some parts more than others. Unfortunately (or maybe fortunately), the BSA doesn’t really seem to be taking a headcount to see which features/bugs are most important. After all, I’m way less interested in getting a market-driven number of cupholders in my car than I am in crashworthiness. 
