As many of you may know, I primarily practice one-handed solving. Becasue of this, I am constantly trying of new ways to improve upon my one-handed solving method, which is currently CFOP with COLL and a little bit of ZB. One method that I have been interested in learning for many years is MGLS. This method seems very promising for OH because of the CLS step, which can be executed entirely 2 gen. There are a few major drawbacks that have kept me from learning this method however. Firstly, although all of the CLS cases can be solved with a 2-generator algorithm, for many cases a 3-generator algorithm is much more efficient, usually RUL. While RUL algorithms are nice for OH, they are nowhere near as easy to execute quickly as RU algorithms. Secondly, there is a very last number of algorithms required for the CLS step - 108 cases. Lastly, the COLL and ZBLL algorithms I have learned become almost completely useless for OH.
These three problems inspired an idea. While learning CLS algorithms, I noticed that all of the algorithms where the DRF corner was permuted, but not necessatily oriented, were really really fast. If I could design a method such that on the CLS step, those 23 algorithms occured, the "CLS" step would be much more efficient. This would solve the first problem with MGLS. Of course, this reduction in algorithms would not come for free. I would have to learn some algorithms that would guarantee that only those 23 cases popped up in solves. What I decided to do was move these to the ELS step. Instead of orienting all edges and solving one edge, my idea was to orient all edges, solve one edge, and solve permutation of the LS corner. In order to do this consistantly, it would require about 50 algorithms. This solved the second problem with MGLS. In total, MGLS consists of 21 + 108 (ELS + CLS) algorithms, and my new idea consisted of ~50 + 23. Much less than MGLS.
As for the third problem with MGLS, I would be able to use COLL/ZBLL in 1/3 solves since the corner has 3 possible orientations and ZBLL and COLL work for one of those orientations. This meant that I wouldn't have to completely abandon those ~60 algorithms I had learned. Now for the the last part. What are the algorithms like? This is mainly a concern for the first step since we know that the second step algorithms are very fast since this entire method was based around that. I started compiling a list of algorithms for the first step and the results look promising. For the first F2L case, the most basic one ( R U' R') the 8 algorithms averages 7.0 ETM. For the second F2L case (R U R') the 8 algorithms avergaes 8.125 ETM. These are surprisingly low to me since I chose these algorithms based on ease of execution, not movecount. Below is a list of the 16 algorithms I have come up with thus far. I will be periodically updating this list as I have time. These may be a little awkward for 2H, but they are quite nice for OH.
Edge Orient WRT RU
Corner at URF
Case 1
-1 (U2) r U' r' U r R' U2 R U r' (11 ETM)
-2 (U2) R U' y R U' R' F' (7 ETM)
-3 R' F R2 U R' U' F' (7 ETM)
-4 (y') R' U' R2 x' U' R' y' U2 R U' (11 ETM)
-5 (U y z ) U' R U x' z' R U' R' (8 ETM)
-6 R' F R F' (4 ETM)
-7 (U x ) U' r' U' r U (5 ETM)
-8 (U) R U' R' (3 ETM)
7.0 avg ETM
Case 2
-1 (U' y') R' U R2 x' U' R' z x R2 U R' (10 ETM)
-2 R U2 y R U' R' F' ( 8 ETM)
-3 R U y R U R' U' F' (8 ETM)
-4 (U) R U2 R2 x' z' R U R' (8 ETM)
-5 (y' U') R' U2 R x' U' R U R' (9 ETM)
-6 (y' U' )R' U2 R U y R U' R' (9 ETM)
-7 U2 r U' r' U' r U r' (10 ETM)
-8 R U R' (3 ETM)
8.125 avg ETM