I've been thinking along these lines, and looking at some general puzzle simulators such as

Magic Tile, gelatinbrain, and pCube.

One possible start is to first define a symmetry class in 3D. (For instance, you might

use x and y moves to generate your symmetry, which generate O_h, the symmetry of

the cube in space. Or you might use the symmetry of any of the Archimedean solids.)

Then you can define your shape. Perhaps it is a sphere, or just one of the solids

themselves. The shape can be defined by planes (multiplied by the symmetry). The

key thing is the shape has a visible exterior.

Next you define cutting planes. These define your cubies. The cutting planes might

be planes, or possibly they can be solids of revolution of splines or other curves.

Next you define your moves. By default the moves will simply be all those that preserve

the shape, but you can add restrictions to this set, or extend it by jumbling moves.

Restrictions might include things like bandaging.

Once all this is done, you do some work to simulate the possible moves of the entity

using a bit of geometry and perhaps physics, generating a permutation representation

(or perhaps even just an operational black-box representation) to end up with a

useful model.

I think the key things here are:

The description should be as concise as possible, exploiting symmetry and convention

so simple things are simple, but permitting extensions for common puzzles. And the description should be *data*, not code, if possible.

The description and even initial simulation should be based on geometry, not on some

table of numbers (permutations), because visualization is important.

For instance, a Rubik's cube might be defined by something like the following:

Symmetry: cubical.

Shape: Plane (1,0,0)=30 (read, 1x + 0y + 0z = 30), multiplied by symmetry.

Cuts: Plane (1,0,0)=10 (read, 1x + 0y + 0z = 10), multiplied by symmetry.

Moves: All physically realizable that preserve shape (the default.)

Of course you still want to label your moves, color your faces, etc., and I have some

thoughts on that too, but they are too long to fit in this post.

So that's why I think that permutation matrices are the wrong approach.