That was the part I hated most, I didn't even bother memorizing the corner sequences until 2 years after I started using the method.
Yeah, its a bit daunting to digest all those cases. It kinda goes against my inherent laziness. That's also why I love the waterman method, but will never learn the full system.
Probably at least most of them are like that. Not all shortcuts are useful when solving for speed though. Some are hard to recognize fast.
Generally, if you have more special cases than you have orthodox cases, you are drifting into fewest move challenge territory, and farther away from speedsolving, specifically because of the time burned up trying to recall which particular special case you are looking at.
Can you explain what exactly you are doing? Are you getting ACube to give all possible sequences, then you check each one to see what it does?
Man, I only
wish it was that easy. I am manually checking all 2 187 possible algorithms in the 7 move set. I did not run A Cube. I reviewed what my data entry options were, and what the program checks for. Assume that a solved cube starts with yellow on top, orange on the left, red right, green back, white down, blue front.
What A Cube will check is how to get all six edges oriented with the yellow center on top. The problem is that we need to check for all possible cases which meet
our requirements, which are:
LU and RU oriented in DF and DB position (or swapped)
With the white center on top, with white or yellow edge facelets on the U face
OR
With the yellow center on top, with white or yellow edge facelets on the U face
OR
With the green center on top, with green or blue edge facelets on the U face
OR
With the blue center on top, with green or blue edge facelets on the U face
So if I were to just check those cases generated by one of the conventional programs, I would potentially miss out on 75% of the potential algorithms. This is why you were able to find shorter algs than the originals I found using Ron's sticker mode solver. It can't recognize end states that we like as solved.
Here's what my theoretical orientation program would do, and how it would work, keeping the following assumptions and visuals in mind:
Our cube only has 4 colors:
L face yellow
R face white
F face red
B face red
U face green
D face green
Our cube only allows for 6 moves: U, U2, U', M, M2, M'
Our program only checks the location of the 6 edges, which facelet of each edge cubie (except for UL and UR) is on the U or D face (red/green), and what color center is in the U face (red/green). UL and UR edges are either oriented (Y, W), or flipped (y,w)
Data for the start position is entered to make a 7 character string which follows this form: UL UR UB UF DF DB Center
So and all flipped start position would be entered as:
GGGGywR
or
RRRRywG
or as above, with yw transposed. The program could just have yy or ww if we didn't care to track UL or UR as unique,
Solved would be entered like this, assuming that we were looking to find one of the 11 cases:
GGGGYWG
or
RRRRYWR
or as above, with UL and UR represented by the same color.
Then, the program would apply algorithms and check the resulting string with the
set of acceptable end states, and print out those algorithms which match one of the defined strings in our set.
No program out there right now can do this.
I can totally write this out in pseudocode, but am programming language illiterate. I might try to write it out in Liberty Basic, but am short on time to do so right now.
Just to update:
M U' M U M' U2 M U' M U' M (11,12) - UF/UB
Alternative: M'U2M'UMUM'U'M' (9) - I also found F2M'UMUM'UMUF2 but it isn't comfortable.
There is a problem with your first alternative. If you do the inverse of my algorithm to set up the pattern and do your first alternative, it leaves all U layer edges flipped! I do not understand why that is though.
I don't really intend to personally develop every single one of my thoughts to the fullest potential. Most of the time, this happens 
