Hashing has a different behavior for "bare" BigFloat's and unit-ed Quantity{BigFloat}'s. For the former, hash is unaffected by BigFloat's data address in memory, stored in its d field; while for the latter, hash do seem to take the data memory address into account, so that equal numerical values hash the same for "bare" numbers, irrespectively of memory location, and can hash differently for same unit-ed Quantity-ies:

Take a, b, and c which are numerically equal to BigFloat(1//7), but a.d === c.d and a.d !== b.d:

julia> [a.d, b.d, c.d] # a and c are the same, but b resides in a different location
3-element Array{Ptr{UInt64},1}:
 Ptr{UInt64} @0x00007fc23e2a2798
 Ptr{UInt64} @0x00007fc23f92d6d8
 Ptr{UInt64} @0x00007fc23e2a2798

julia> a == c == b # They have the same values...
true

julia> a === c !== b # ...but are NOT identical (as === performs bit-level comparison)
true

julia> map(hash, [a, b, c]) # The bare numbers hash the SAME...
3-element Array{UInt64,1}:
 0x861a441bf6ee33e9
 0x861a441bf6ee33e9
 0x861a441bf6ee33e9

julia> map(x -> hash(x * u"m"), [a, b, c]) # ...however, their Quantity-ies do not!
3-element Array{UInt64,1}:
 0x6bc1521c2c63173d
 0xe8f1b97e24b56c91
 0x6bc1521c2c63173d

So, should hashing of Quantity{BigFloat} behave differently to those of BigFloat's?

I see it as inconsistent behavior, that may lead to false negative tests that work just fine for Quantity{Float64}, Quantity{Float32}, etc.