Hi Luc,
It does sound like a typical data skew problem.
You have 63% of the column = " ", this skews the total density so we reckon that for a single row from the left a <large> number of rows will be returned from the inner table.
You could argue that the positioned lookup might still be quicker, but my guess would be the data row\page cluster ratio for the index is fairly low. Not a fragmentation issue though, as the drcr for this index is a measure of how correlated the index is to the data with respect to access via that index. I.e. for each row it needs to fetch is it likely the next row resides on the same page etc. You are doing a select * so it needs data level access, assuming your small example is representative.
On 125x you should have been able to work around the data skew by running this:-
sp_modifystats 'A', 'ref1', 'REMOVE_SKEW_FROM_DENSITY'
This will replace the total density with the range cell density (which will be much, much more selective).
It will be lost when you next run update stats though so you would need to add it to the stats scripts.
On 15.7 we have the ability to perform a histogram merge between the attributes on either side of the join, we can only do this when we have histograms in place though. Without them it should fall back on the total density so the above sp_modifystats should do the trick.
The other alternative is to generate a histogram for that single row in B so we can then generate a join histogram - update statistics B (ref1)
HTH,
Simon