Thanks for your report.
The makebearoff code was written last millennium, and the problem you're seeing is probably caused by some overflow problem in the code. These kind of stuff was hard to check back in the 90s.
I guess it is fixable but ...
* Assuming you are able to solve the code issue (which is probably an overflow), then you first need at computer with enough memory. 32GB RAM computers are not uncommon these days, so that might not be a problem.
* Next, in the 90s and early 2000s when this code was written, developers thought about size (and they still do). To mitigate the size of the datafile the probabilities are stored in 16bit precision. With this precision the the values actually deviate from the true values in the higher end of the bearoff table.
* The overflow bug in makebearoff, probably also have the same corresponding bug in the GNU Backgammon code. I far from sure a 15x6 bearoff database will work OOTB in GNU Backgammon.
* The most severe problem tough, which I've just been aware of, is that a true 2-sided bearoff database, will give evaluation differences from onside bearoff so high, that race bearin positions will be played incorrectly. The current race neural network is trained to match the probabilities given by a one-sided bearoff database. Using a setup with the current race net + full two sided beaoff database, will do incorrect bearin moves (at least at lower plies).
So... Having a full twosided beaoff database (15 checkers on 6 points) will probably not improve the playing abilities of GNU Backgammon except in pure bearoff positions.
Well.... that said. It is interesting to sometimes know the real winning probabilities in a bearoff position. After all we are geeks.... I have written a code that do generate a full 15 checker bearoff database with 32bit precision, but it's not storing the cubeful numbers. That makes it 54264 x
54264 x 4 bytes ~= 11GB (big). My database is incompatible with GNU Backgammon, but I'm able to find an "exact" winning probability without doing a rollout.
-Øystein
...