As far as I see this mismatch between the HM and the WD still exists in version 8.1 of the HM.

For example in getInterMergeCandidates() if pcCULeft fails parallel merge test then it is set to NULL.

    if (!pcCULeft->isDiffMER(xP -1, yP+nPSH-1, xP, yP))
    {
      pcCULeft = NULL;
    }

This means that pcCUAbove can still be added even if it has the same motion as pcCULeft.

  if ( pcCUAbove && !pcCUAbove->isIntra( uiAbovePartIdx ) 
    && !(uiPUIdx == 1 && (cCurPS == SIZE_2NxN || cCurPS == SIZE_2NxnU || cCurPS == SIZE_2NxnD))
    && ( !pcCULeft || pcCULeft->isIntra( uiLeftPartIdx ) || !pcCULeft->hasEqualMotion( uiLeftPartIdx, pcCUAbove, uiAbovePartIdx ) ) )
{
... Add above predictor
}

However in the WD it states that B1 will not be added if.

–	N is equal to B1 and the prediction units covering luma location ( xA1, yA1 ) and luma location ( xN, yN ) have 
        the same motion vectors and the same reference indices

This does not test if A1 was available, just if it has the same MV & Ref, and hence is different from the HM.

Perhaps the clause should read something like:

–	N is equal to B1 and the prediction units covering luma location ( xA1, yA1 ) and luma location ( xN, yN ) have 
        the same motion vectors and the same reference indices and predFlagLXA1 is equal to 1

If so then there would still be a mismatch as pcCULeft is not set to NULL if it fails the following test.

    !(uiPUIdx == 1 && (cCurPS == SIZE_2NxN || cCurPS == SIZE_2NxnU || cCurPS == SIZE_2NxnD))

Another mismatch between the WD text and the HM software on derivation of spatial merging candidates is that:
In HM8, when N is Intra coded block, there is no MVP candidate related to N.
However in WD, availableFlagN is set equal to 1 even if N is Intra coded block. (availableFlagN=1 means the MVP candidate related to N will be added to list)

it seems to solve the issue by following changes (the last sentence is added):
– If one or more of the following conditions are true with X being replaced by 0 and 1, the availableFlagN is set equal to 0, both components mvLXN are set equal to 0, refIdxLXN is set equal to −1 and predFlagLXN is set equal to 0.
– (xP >> (log2_parallel_merge_level_minus2 + 2)) is equal to (xN >> (log2_parallel_merge_level_minus2 + 2)) and (yP >> (log2_parallel_merge_level_minus2 + 2)) is equal to (yN >> (log2_parallel_merge_level_minus2 + 2)).
– N is equal to B2 and availableFlagA0 + availableFlagA1 + availableFlagB0 + availableFlagB1 is equal to 4.
– availableN is equal to FALSE
– PredMode[xN][yN] is equal to MODE_INTRA
...

The second mismatch does not exists since the condition on INTRA is already checked in "6.4.2 Derivation process for prediction block availability" used to derive availableN.

You are right, the second mismatch does not exist.
At the meantime, I also believe that the first mismatch has been fixed in HM9 where a Macro "MERGE_CLEANUP_AND_K0197" is introduced.

So, can this be closed as "fixed in HM 9.0"?

Yes I agree that it appears to be fixed.