Since the position of the last two edges is forced you can use a EP* from 0 to 12!/2 -1 by combining the index of the combination of 10 edges (Binomial(12,10) possibilities) with the 10! possible permutations of these 10 edges (Binomial(12,10)*10! = 12!/2). I used this kind of coordinate several times in my programs. This saves 1 bit.

Of course you can now build the total Index for example with

3^7(8!(2^11 EP*+EO)+CP)+CO

and you get an unique index from 0...43252003274489856000-1 for each cube, which needs 66 Bits.

I have to ask, why do we need a particularly concise representation? If you're not storing many positions, the

difference between a cubie representation (20 bytes, one per cubie, each holding a value of 0..23) and a 66-bit

index (which generally really takes 128 bits or 16 bytes due to alignment) is not a big deal.

Directly indexing positions has a certain elegance, but it's not too far from just lexicographically ordering a

working cubie representation.

The cubie representation permits operations such as moves, inversions, reorientations, and direct position

multiplication (pretty much the standard group operations). And it's pretty quick to turn into an index, or to

derive from an index.

So if the reason you want such a concise representation is to store many many positions, then you get into

ideas of how to efficiently store a finite subset of a large finite set, or conversely, how many distinct

elements you can store in a given amount of memory. While you can't do a whole lot better than 66 bits

per, you can do somewhat better, depending on the operations you need to perform and their required

relative speed.

For instance, to store 200M positions (say, known distance-20 positions) concisely, you

might just index them, sort the indices, and then break them out into about 5000 separate lists by the

leading 13 bits, reducing the bit count of each entry to about 53 bits (and paying a small amount of

overhead for the required datastructures to keep track of this information). If access speed is not important,

you can just encode the delta between adjacent entries in a big sorted list; this would probably be about 40

bits per position (using Huffman or arithmetic coding to encode the bit length of each entry).

But you have to ask yourself if saving 26 bits out of 66 or about 40% is worth all these heroics.