Setting up a similar map to what you have described, and accessing via a bean property I still found the errors you describe. This issue was fairly difficult to triage, but my final diagnosis is that it is indicative of a bug. It is interesting to note that the value[@name='a'] != value[@name='b] approach succeeded, and of course the two approaches should yield equivalent results for any key conforming to QName restrictions. I would still consider it dangerous to depend on null values in JXPath, however. For example, if you add a mapping of "d":0 to your map, you will find that value[@name='d'] = value[@name='b'] because the fact that d refers to a numeric type forces the conversion of b's null value to a number, 0.0. XPath is tricky this way, and JXPath, dealing with types unknown to the XPath specification, only becomes trickier.
Having said all that, and to return to the issue at hand, I found that certain existing JXPath tests assert that it should be possible to get a null value from the expression bean.nullProperty, but that iterating pointers from the expression bean.nullProperty should yield no results. But this assigns a Java-centric meaning to XPath's  test, and it is my judgment that this is overstepping given that Javadoc for relevant methods states that non-Collection items should be treated as having length 1. Making the conscious decision to change an existing unit test is not a decision to make lightly, but in this case my opinion is that it is warranted.