Okay, so I kept digging and found the most likely cause of the problem. Two things are happening here, and frankly, I think they are both flaws that Managing Data (Esri) should look into. The first part of the problem is that the Split (Analysis) tool only uses the first word in the Split Field, so that "Altara Elementary" simply becomes "Altara" in the output. The second problem is that it eliminates (seemingly randomly) any additional rows with the same first word from the output. Thus "Copper Canyon ES" and "Copper Hills", both being truncated to "Copper", evidently cannot coexist, and one is dropped from the output (in this case, "Copper Hills").
Based on the 11 features that failed to produce an output (see "SplitFailRemainder" table), it appears at first glance that the row with the lower OBJECTID (i.e. the one that is detected first if starting at 1) is the one that gets to stay; however, randomness strikes yet again when we get to "Jordan Hills" and "Jordan Ridge", because as you can see in the "SplitFailRemainder" table, "Jordan Hills ES" is the one that failed to produce an output, but it originally had the lower OBJECTID of 28 (see "Elementary_boundaries" table). This anomaly occurs with two other words/names from my list, but the rest of the duplicates are eliminated by whichever has the higher OBJECTID.
So my workaround was very similar to yours, except that I really wanted to maintain the school name as the names for the output features; therefore, instead of adding a new field, I simply removed the spaces from the school names using the Python parser !myfield!.replace(" ","") in Field Calculator, and that kept the names distinct so that none were truncated or omitted.
But again, I think this is flawed functionality that would require these workarounds for something as relatively simple as this. Thanks for your post on this subject and all who responded. It was exactly the info I needed.
P.S. The "isolation" of the 11 polygons I mentioned in my first post most likely didn't work because I was only using a definition query to isolate. My guess is that if I had exported those 11 rows to a new feature class, they would have Split just fine (with the exception of duplicates, of course). Either way, I needed to run the Split on all 133 features to get the names I wanted, so it worked out anyhow.