> There is a 1:1 correspondence between visited configurations and queue entries, so for total RAM usage it actually doesn't matter what information you're storing in which one.

It does if you are allocating the visited state map up front. The queue grows as you explore the states. As you approach every possible state then it will become 1:1 with the visited states. But until then it will be smaller.

> but 256 * 0.5 GB is just 128 GB, not terabytes

You are right. My math was off this time. I can actually fit this on my desktop but WebAssembly is an important target for me and browsers only support 32 bit wasm. So I would probably need an alternative implementation there.

I converted your puzzles to my solver out of curiosity:

17: https://ricochetrobots.kevincox.ca/#s=EBBBCBECA4CBAAEAIQIBQI... 1.3s

27: https://ricochetrobots.kevincox.ca/#s=EBBBQCEQA0ABAkEAAQARII... 2.4s.

Thanks for these examples, they are good to add to my benchmarks. Right now the slowest puzzle I am aware of is this 20 move with mirrors. https://ricochetrobots.kevincox.ca/#s=EBAJIAEAEQQhAAEAQYAJAI... It takes about 5.4s.

Mirrors make it much harder because robots are not interchangeable, the slowest puzzle without mirrors I have is 25 moves https://ricochetrobots.kevincox.ca/#s=EBAhQBEQBUABAwEAQQARII.... It takes 4.5s

All times were in the wasm build. The native build is faster but it varies a lot by puzzle, not sure why that is. Between 10 and 50% faster.