I don't know why the two files I attached above are 0 bytes. I'm attaching new 
versions here.

The problem here is that inside bn1() there is no indication that the user set 
both parameters to the same variable. Therefore bn1() is evaluated as though 
they were distinct, and, emerging on the other side, nothing is done to ensure 
that they are indeed the same.

Ideally, we should bring the implicit $B = $N constraint with us from the 
moment we start evaluating bn1. This could perhaps be done by not running bn1 
as declared, but instead running

  bn($B,$I), bn($I,$N), $B = $N

which the optimizer would automatically turn into

  bn($B,$I), $B = $N, bn($I,$N)

which would again mean that the last bn would run with both columns bound, and 
so the final broader-narrower predicate would filter instead of producing more 
temporary results to be handled later.

Actually doing this in practice seems a bit tricky, though.

A simpler and more straightforward solution would be to fix the code that 
translates the result of bn1 into the variables used in the calling context 
(that is, the top-level query) to take into account the restriction that both 
result rows that map to $B have to agree for a row to be acceptable. This 
should have been there all along, of course.

Fixed by taking the second route in revision 1188. Added your example data and 
query as the test case in the test suite. I hope that is OK.

That's great! Thanks.