I think after working a bit more with the API that I withdraw my suggestion. I think that calling Should() is the right thing to do within an extension to the API. It wraps nicely around everything.
For instance, I'm writing a HaveRow extension, that given an object[] validates that a row from the database contains the same row as expected. I have implemented it like this:
public AndConstraint<DataTableAssertions> HaveRow(int rowid, object[] expectedrow, string reason, params object[] reasonArgs) { var row = Subject.Rows.Cast<DataRow>().FirstOrDefault(r => r.Field<int>(0) == rowid); if (row != null) { var expected = rowid.ToSingletonSequence<object>().Concat(expectedrow).Realize(); row.ItemArray.Should() .HaveSameCount(expected).And .ContainInOrder(expected, reason, reasonArgs); } else { Execute.Verification.BecauseOf(reason, reasonArgs).FailWith( "Expected a data row in the data set {0} to have an identifier {1}{reason}, but no row did not appear.", (object)Subject, (object)rowid); } return new AndConstraint<DataTableAssertions>(this); }
Where I simply forward the actual verification to the row to an existing implementation in the fluentassertions using Should(). Just as it should be (pun intended).