Speedcubing kid can skip last layer by learning 3915 algorithms for every case

It doesn’t work in general for any arbitrary T of course since it’s not commutative as you noted. This is more of a cubing thing than an algebra thing.

in his example, let's say there's some 3-cycle (123) the cuber knows. But really, the cuber wants to transform like (479).

Conjugation being equivalent to a group action implies the cuber only needs to find a group that permutes 1->4, 2->7, 3->9.

Let's say one is found: (14)(27)(39)...

gTg' => [(14)(27)(39)...](123)[(14)(27)(39)...]' = (479)

Suppose we want to move what is at 4 => 8, 8 => 9, and 9 => 4, leaving everything else unchanged but the only permutation we know that moves 3 items in a cycle leaving everything else unchanged moves 1 => 2, 2 => 3, and 3 => 1. This latter permutation we'll call T.

Consider any permutation g that does 4 => 1, 8 => 2, and 9 => 3. It may or may not move other things. The inverse of g, g', does 1 => 4, 2 => 8, and 3 => 9.

Let's work out what happens if we do gTg'.

First let is just look at items 4, 8, and 9, which are at positions 4, 8, and 9, respectively. g takes those to positions 1, 2, and 3. Then T takes positions 1, 2, 3 to 2, 3, 1, so what we have in positions 1, 2, 3 is items 9, 4, and 8 in that order. Finally g' takes what is in positions 1, 2, and 3 to 4, 8, and 9, so we end up with item 9 at 4, item 4 at 8, and item 8 at 9.

So for positions 4, 8, and 9, gTg' does 4 => 8, 8 => 9, and 9 => 4.

g necessarily had to move whatever was in 1, 2, and 3 out of the way to make room for 4, 8, and 9, so we have to consider what happens to what was at 1, 2, 3. Let's just look at 1. It has to go somewhere. Call that position p. So g does 1 => p, where p is not 1, 2, or 3. g' does p => 1.

T only moves things in 1, 2, 3, so after g moves whatever was originally at 1 to p, T leaves it along. g' then does p => 1, putting it back where it came from. So we see that gTg' does not move 1. Same reasoning applies for 2 and 3.

If g moves any x else other than 1, 2, 3, 4, 8, 9 we can use the same argument. x => y for some y that is not 1, 2, or 3. T does not move y. g' does y => x, putting x back where it came from.

Thus we can conclude that gTg' only moves 4, 8, and 9.

Another way you can visualize why it works when applied to the cube is by cheating a bit. First do g legitimately by actually doing the moves on your cube. Then instead of actually doing the moves for T just repaint the faces on the cubies that T permutes so it looks like you did T. Then legitimately do g'.

Since you haven't actually done T the only actual moves you have done are gg' which as you've noted is of course I, so everything is back where it started but with some of the faces on some of the cubies repainted. The repainted faces are exactly those that would have ended up moved if you had actually done T. The faces not repainted are those that would be undisturbed by gTg'.

The key here is that all these mappings are finite, one to one, and onto (bijective if we want to get fancy). If you apply such a mapping from A to B, then permute k elements in B, and then apply the inverse mapping, you end up with k elements permuted in A.

I'm skeptical but also have no authority on memorization or rubiks cubes... I've also seen crazier things lol