I have just run all the tests and haven't found a place when duplicated description would appear.
I have used a conditional breakpoint and debugged all the tests.

@dennisdoomen are you aware of MCVE for the #738 that this fix does not cover?

After @jnyrup comment, I found that I misspelt the assertion in test:
.Should().NotMatch("*Try conversion of all members*", "conversion description should be present");
should be
.Should().**Match**("*Try conversion of all members*", "conversion description should be present");
hence I have a problem to fix.

are you aware of MCVE for the #738 that this fix does not cover?

No, I just noticed it while working on some other fix.

Thanks.
While debugging I start to see that problem with ConversionSelector.Clone is just the tip of the iceberg ;-).
Work in progress to fixing the root causes.

Ok, by now I think I have gotten to the bottom of the issue. The more facts I gathered, the more clear it was that until this PR, the feature was working almost by accident :-).

The most important parts of the code to understand it are:

• ConversionSelector.Clone() copied the StringBuilder reference instead of cloning. @dennisdoomen found a case when the description was duplicated, but because default static StringBuilder was copied all over the place, the description could be repeated without upped bound. However, cloning would also be incorrect, because of the conditional logic in ConvertionSelector.ToString(). One of the incorrect scenarios would be when you clone ConvertionSelector without rules, and you get "Without automatic conversion.". Next, you add some conversion rule and try to add the description the builder, but "Without automatic conversion." is not erased! The only solution was to make ConvertionSelector delay building the description string until ToString is called.

• SelfReferenceEquivalencyAssertionOptions constructor that copies from defaults had following line: userEquivalencySteps.AddRange(defaults.UserEquivalencySteps);. Seems logical, but when we go to UserEquivalencySteps implementation we can see that its not a single retrieval of the list but userEquivalencySteps.Concat(new[] { new TryConversionStep(ConversionSelector) });. This code generates convertion step with a current selector. So when it copied from defaults it used defaults.ConvertionSelector instead of using cloned selector. The only solution I found yet is to inject ConvertionSelector

I plan to add some more tests tomorrow, but I could use some review. I hope I did not miss anything important.

Ready for merge(with squash).

I have added one test checking the exception message exactly, I hope you won't crucify me for that :-). My intent was to have at least one test that verifies the whole mechanism of gathering descriptions from the equivalency steps.

As it was discussed, the PR introduces minor breaking change in public API.