Summary

A filtered count over an owned (embedded) collection, used as a projection leaf:

db.Blogs.Select(b => new { b.Title, N = b.Posts.Count(p => p.Rank > 0) })

throws System.InvalidOperationException — "The LINQ expression 'o' could not be translated. Either rewrite the query in a form that can be translated, or switch to client evaluation explicitly by inserting a call to 'AsEnumerable', 'AsAsyncEnumerable', 'ToList', or 'ToListAsync'."

Measured under all three MongoQueryMode values (Native, DriverLinq, NativeOnly), identical exception and identical stack location in each. There is no mode in which this shape returns results, and therefore no driver-LINQ oracle for it.

Where it crashes

At translation time, inside
MongoDB.EntityFrameworkCore.Query.Visitors.MongoProjectionBindingExpressionVisitor.Translate,
called unconditionally from MongoQueryableMethodTranslatingExpressionVisitor.TranslateSelect — i.e. before MongoQueryMode is ever read by the compile-time gate in MongoShapedQueryCompilingExpressionVisitor. That is why the mode makes no difference to whether it crashes; the visitor cannot bind the inner Count(p => p.Rank > 0) lambda's parameter p when walking the anonymous-type NewExpression.

Pre-existing

Neither caused nor fixed by the owned-collection count work. Neither the .Countin-a-predicate slice nor the count-projection slice touches predicatedCount recognition inside a projection; this shape was never routed through either one's code paths.

Same shape of defect as EF-357 (a projection-binding gap that hard-fails in every mode rather than declining gracefully), which is why it is filed as a bug rather than tracked as a native-coverage gap.

Consequence for the planned follow-on

The provider's documentation previously framed a filtered count as "deferred for cost, not impossibility — expressible as $size over $filter". The rendering claim still stands. The graceful-fallback assumption does not: a future "filtered count projection" slice is not a fallback-to-native widening, because the shape never gets as far as the gate that reads MongoQueryMode. It must first fix (or route around) this translation-time crash.

Repro / documenting test

NativeOwnedCollectionCountTests.Filtered_count_projection_is_a_known_preexisting_hard_fail_in_every_mode
(branch EF-322-owned-collection-count-projection) loops over all three modes and asserts the InvalidOperationException in each.

Per the versioning rubric in AGENTS.md, the exception type is not part of the provider's contract for an unsupported shape. The test exists to notice change in either direction and prompt re-measurement, not to freeze InvalidOperationException as expected behaviour.

Suggested fix

Either support the shape natively — {{{ $size: { $filter: { input:

, as: "p", cond: <pred> } } }}}, which the existing MongoSizeExpression / MongoAggregationExpressionRenderer machinery is close to — or, failing that, make MongoProjectionBindingExpressionVisitor decline the shape so it falls back and returns correct results instead of throwing in every mode.