In Stockfish' material imbalance code it is easy (well, I hope I got it right somewhat ) to make a small correction to code so that if there are two bishops of the same color, the bishop pair bonus is not awarded. But I doubt the effect can be measured the normal way, in games you will rarely see a bishop underpromotion with one of the original bishops gone. Of course if you just test situations where this has actually occurred, same colour bishop pair compared to normal bishop pair, it is possible. But I have not actually done this for Rainbow Serpent.

I have increased the value for the bishop pair bonus (different colour bishops) a bit that is also found here in the material imbalance table, the first number in this array:

const int LinearCoefficients[6] = { 1690, -162, -1172, -190, 105, 26 };

In Stockfish:

const int LinearCoefficients[6] = { 1617, -162, -1172, -190, 105, 26 };

The 1690, in Stockfish 1617, coefficient is for the bishop pair, originally the 6 coefficients are for no piecetype, pawn, knight, bishop, rook and queen respectively but the NO_PIECE_TYPE is here replaced by the bishop pair. See also the comments here below and small changes for correcting if the bishops are of the same color I added in the piece of code from Stockfish material imbalance:

Rainbow Serpent:

  // Evaluate the material imbalance. We use NO_PIECE_TYPE as a place holder
  // for the bishop pair "extended piece", this allow us to be more flexible
  // in defining bishop pair bonuses.
  const bool bishoppairWhite = pos.piece_count(WHITE, BISHOP) > 1 && opposite_colors(pos.piece_list(WHITE, BISHOP)[0], pos.piece_list(WHITE, BISHOP)[1]);
  const bool bishoppairBlack = pos.piece_count(BLACK, BISHOP) > 1 && opposite_colors(pos.piece_list(BLACK, BISHOP)[0], pos.piece_list(BLACK, BISHOP)[1]);
  const int pieceCount[2][8] = {
  { bishoppairWhite                   , pos.piece_count(WHITE, PAWN), pos.piece_count(WHITE, KNIGHT),
    pos.piece_count(WHITE, BISHOP)    , pos.piece_count(WHITE, ROOK), pos.piece_count(WHITE, QUEEN) },
  { bishoppairBlack                   , pos.piece_count(BLACK, PAWN), pos.piece_count(BLACK, KNIGHT),
    pos.piece_count(BLACK, BISHOP)    , pos.piece_count(BLACK, ROOK), pos.piece_count(BLACK, QUEEN) } };


In Stockfish master it is (only in this comment) still referred to as PIECE_TYPE_NONE but in the functional code Marco changed this name to NO_PIECE_TYPE

  // Evaluate the material imbalance. We use PIECE_TYPE_NONE as a place holder
  // for the bishop pair "extended piece", this allow us to be more flexible
  // in defining bishop pair bonuses.
  const int pieceCount[2][8] = {
  { pos.piece_count(WHITE, BISHOP) > 1, pos.piece_count(WHITE, PAWN), pos.piece_count(WHITE, KNIGHT),
    pos.piece_count(WHITE, BISHOP)    , pos.piece_count(WHITE, ROOK), pos.piece_count(WHITE, QUEEN) },
  { pos.piece_count(BLACK, BISHOP) > 1, pos.piece_count(BLACK, PAWN), pos.piece_count(BLACK, KNIGHT),
    pos.piece_count(BLACK, BISHOP)    , pos.piece_count(BLACK, ROOK), pos.piece_count(BLACK, QUEEN) } };

  mi->value = (int16_t)((imbalance<WHITE>(pieceCount) - imbalance<BLACK>(pieceCount)) / 16);
  return mi;
}


A value of 1690 is later divided by 16 (you can see that in the last line of above codeblock, the ))/ 16); division
) so that is ~= 105 (decimal) and the value of a pawn in the endgame is indeed about twice that:
  const Value PawnValueEndgame   = Value(0x102);
0x102 hexadecimal is 258 decimal value. I think this means that 1690 (mostly a guess from my side) is still a bit low but you would have to factor in all the other corrections in the material imbalance table, 1690 is only the linear term involving the bishop pair, there are also higher order corrections that are impossible to tune by hand because too many. (there are some more changes in the material imbalance table of RS so the bishop pair values can't be totally compared to the Stockfish code bishop pair coefficients, without looking at the other imbalance table changes here as well, and changes to bishop eval elsewhere)

Regards, Eelco

>calculating +3 plies deeper internally

Why, how? I think it is not Rybka but some GUIs swallows first lines as it shows still zero kN.
While some are not, look attachment...
And yes, different engines must play at timed control.