This most likely falls under "design choice".
We do not support all vacuous truths.
See e.g. #1492 for a related discussion on this.

Do you have a more realistic example where this is a problem for you?
I'm inclined to ask "why would you want to test use AllSatisfy on an empty collection"?

I'm inclined to ask "why would you want to test use AllSatisfy on an empty collection"?

Exactly. If your test is expecting an empty collection, make that explicit. I can't imagine a test that sometimes expects an empty collection and sometimes a collection which items match the predicates.

This most likely falls under "design choice". We do not support all vacuous truths. See e.g. #1492 for a related discussion on this.

Do you have a more realistic example where this is a problem for you? I'm inclined to ask "why would you want to test use AllSatisfy on an empty collection"?

In fact, I came across this bug because I had made a parameterized test that would check required properties of the result. Initially, I had just given nontrivial test case input (producing among other objects a nonempty list), but the code should also work for trivial input (producing among other objects an empty list), and the same properties should still apply for the result. When I added the trivial test case, the test failed.

I was in fact surprised that .AllSatisfy has this unconventional behaviour, especially as it is not noted in its documentation. Also, I think most mathematicians (of whom quite a lot are employed as IT developers) would find vacuous truths most natural. The fact that someone else raised a similar issue previously seems to be an indication that this is what many developers expect.

If you have a need for ensuring a nonempty list as well as a property on each element, I would expect you could do something like

.Should().NotBeEmpty().And.AllSatisfy(...)

making your intention clear and explicit.

Note that I am not able to fluently assert "empty or all satisfy" using .AllSatisfy(), as the .Or operator (corresponding to .And) is not part of FluentAssertions.

If you really want to compound the two tests into a single method, I suggest adding a new method .NotBeEmptyAndAllSatisfy(...); this would be more helpful and intention revealing, and prevent developers from inadvertendly making errors in their assertions.

When I added the trivial test case, the test failed.

In trying to understand you case, I have to ask: why would you want to test a vacuous truth?

From #1492
The goal is not to make the API of FA consistent to the underlying .NET framework methods. The goal is to make things explicit and intention revealing.

I think most mathematicians (of whom quite a lot are employed as IT developers) would find vacuous truths most natural.

Conversely I don't think most developers are mathematicians.

From the wiki-page
Outside of mathematics, statements which can be characterized informally as vacuously true can be misleading

The fact that someone else raised a similar issue previously seems to be an indication that this is what many developers expect.

That's selection bias, people don't raise issues with things that works fine 🙃

OK, this is frustrating, and seems to lead to nowhere. I don't find it ureasonable to want to test "no matter how many elements there might be in a result, xs, they should all satisfy P(x)." In parameterized DRY test methods you can easily end up testing results that for some test cases (i.e., parameter sets) are trivial (i.e., zero, empty, null, etc.). If, for instance, you were to test the List.Filter() method, you would naturally give test cases somewhat along these lines:

[Theory]
[MemberData("FilterTestCases")]
public void FilterTest(List<int> xs, Func<int, bool> p) {
  var rs = xs.Filter(p).ToList();
  rs.AllSatisfy(r => p(r));
}
public static object[][] FilterTestCases { get; } = new object[][] {
  new object[] { new List<int>(), x => x > 3 },
  new object[] { new List<int>{ 1, 2, 3, 4, 5 }, x => x > 3 },
  ...
}

Constructively, I suggest either

1. Carefully re-visiting the design decision of bundling two properties (non-emptyness and element satisfactions) into a single assertion method, and make it more orthogonal and intention-revealing by not requiring non-emptyness (as this can easily be fluently asserted using .NotBeEmpty().And), or
2. (As an adequate alternative) add an assertion method .BeEmptyOrAllSatisfy() that does not require the list to be non-empty.

The attractiveness of FluentAssertions is that it is fluent and orthogonal, so that we can naturally express and combine all our assertions within the framework without using C# control statements like if (xs.Any()) xs.AllSatisfy(...).

The current semantics of .AllSatisfy() makes FluentAssertions less attractive.