The difficulty of developing is inherently included in the piece values of the limited-range Rooks. I do replace Knights and Bishops in the FIDE setup with those. In fact I think the Rook itself suffers from that too. It is not replacing a Bishop, but I don't think it really matters much whether it starts on a1 or c1. With FIDE-like Pawns, Rook-like pieces suffer. (This makes it interesting to do piece-value measurements in Berolina, to see if the Rook-like pieces go up in value compared to the FIDE context.)

I guess that what disturbed Betza was that the Cannon is a piece of a value that ought to be developed early. So that would mean that especially R2 and R3 suffer a lot, but that R4, R5, ... R suffer less. After all, Q is easy to develop, but it is a classic mistake to do so. You want the heavy pieces to remain in the back until the light ones have cleared the field for them.

Btw, the Cannon should suffer a lot less than R2/R3. Behind its own Pawns the capture move of the Cannon is developed from the very beginning. In the early days of Fairy-Max I did test the Cannon, btw. From what I recall it was indeed about the value of a Knight. The Cannon is a tricky piece, however. The fact that it has a move that is explicitly dependent on the presence of other pieces makes it a non-constant, and in the late end-game it loses its value completely. One should be skeptical whether a program not taking this into account, but handling it as if it had a constant value, could give you an accurate value determination. In my dedicated Xiangqi engine I noticed that with Cannons it is extremely important that you know when to get rid of them. Wait too long, and you are stuck with worthless Cannons.

As to the software:

The latest WinBoard release ( http://hgm.nubati.net/WinBoard-4.7.0.exe ) contains a pre-installed Fairy-Max in the package. This is not the 'Pair-o-Max' version I am using now, which has been patched for taking account of mating potential of the pieces through some simple heuristics (where the most important recipe is that any score is divided by 2 if the leading side has no Pawns, and even by 8 if he is less than 350 cP ahead in piece material (and pawnless), unless he has a light piece that is marked as having mating potential in its piece definition). The source of that version is on my website, though, and I can easily make it available as a Windows binary that could be used to replace the Fairy-Max in the WinBoard install.

The way you would have to define pieces for Fairy-Max is not very user-friendly, though. I recall having mentioned Spartacus, but I am not sure anymore why at that time I thought that Fairy-Max would be to simple for what you needed. Please refresh my memory. Some limitations are very deeply ingrained in Fairy-Max' design. Some other things can be added in a relatively simple way, and sometimes I make the effort to do that. Lately I added the capability to do limited-range sliders of ranges 3, 4, 5, and this heuristic for judging mating potential. Perhaps this already solves the problems I perceived at that time. If the problem was board-depth, it would be pretty hopeless with Fairy-Max.

Problem is that the Spartacus project is in a sort of sleeper state; I have not worked on it for more than a year, and it has dropped on my list of priorities since I know this year's Computer Olympiad will be in Japan. So I am mostly working on improving my Shogi engine now, and the chances I will get to do any work on Spartacus before August are very slim.