Sort of—that's pretty much the last step of the 8355 method. Roughly two-thirds of the time you'll be left with one twisted last-layer corner (and obviously also one more twisted corner elsewhere); when this happens, just rotate the whole puzzle and do the RDRD thing to fix the two twisted corners.So I had a question: Is it possible to merge OLL and PLL into one phase and do it faster using this R' D' R D algorithm?
R' D' R D swaps the U-R-F corner with the DFR-F-R corner, but it also does a swap of two more corners on the back-right face. Furthermore, these swaps are "twisted": do it twice and you end up with the corners twisted, so you really need to do it a multiple of six times to fix the two back-right corners.
If we're only orienting the corners, we'll be doing R' D' R D twice for every corner that needs to twist anticlockwise and four times for every corner that needs to twist clockwise, so the total number is guaranteed to be a multiple of six. Likewise, if we're only permuting the corners, we'll be doing R' D' R D either 1+5 times or 5+1 times each time we transfer a corner piece from one location to another, so it's again forced to be a multiple of six.
However, if we're simultaneously orienting and permuting the corner pieces like in the 8355 method, this constraint no longer has a reason to hold. When we hit the last corner to solve and it ends up not being a multiple of six, there are two options: just solve it (this leaves three twisted corners total—but this only works on kilominx, not on megaminx, because the edges are messed up) or do R' D' R D a few more times to fix the back-right corners (this leaves two twisted corners total).
If we're only orienting the corners, we'll be doing R' D' R D twice for every corner that needs to twist anticlockwise and four times for every corner that needs to twist clockwise, so the total number is guaranteed to be a multiple of six. Likewise, if we're only permuting the corners, we'll be doing R' D' R D either 1+5 times or 5+1 times each time we transfer a corner piece from one location to another, so it's again forced to be a multiple of six.
However, if we're simultaneously orienting and permuting the corner pieces like in the 8355 method, this constraint no longer has a reason to hold. When we hit the last corner to solve and it ends up not being a multiple of six, there are two options: just solve it (this leaves three twisted corners total—but this only works on kilominx, not on megaminx, because the edges are messed up) or do R' D' R D a few more times to fix the back-right corners (this leaves two twisted corners total).