El siguiente código funciona como se esperaba en (el código subyacente de un UserControl de WPF de un proyecto .NET 4.8 ).

 private async Task DeleteAsync() { try { await ViewModel.DeleteAsync(GetSelectedItems()); } catch (Exception ex) { var doCatch = ex is ValidationException || ex is ExpectedInfoException || ex is ExpectedDbException; if (doCatch) ExeptionHelper.HandleException(ex, AppConstants.ApplicationName); else throw; } }

El siguiente experimento analógico no siempre detecta una excepción en un proyecto .NET 6.0; consulte los comentarios en línea. Mi intento de una muestra de reproducción mínima reproducible aún no está completo, pero espero que alguien ya tenga una suposición educada del motivo.

 private async void DeleteListAsync() { var list = ViewModel.GetSelectedItems( dataGrid.SelectedItems.OfType<ActorModel>().ToList()); try { await ViewModel.DeleteListAsync(list); } catch (Exception ex) when ( ex is ValidationException || ex is ExpectedInfoException || ex is ExpectedDbException) { /* this part does run as expected when() one of those three * custom MyNamespace.Exceptions gets thrown in the previous `try` block. * But unexpectedly *not when thrown inside the nested step-into code of * ViewModel.DeleteListAsync() */ ApplicationHelper.HandleException(ex, Intl.LocalizedConstants.AppName); } catch { /* this part does run as expected when a `new InvalidOperationException("Test")` * or `NotImplementedException()` gets thrown directly in the `try`block. * Also when thrown inside the nested step-into code of * ViewModel.DeleteListAsync() */ throw; } }

[Resuelto]: mucho más tarde, con la ayuda de los comentarios útiles, encontré una declaración de espera faltante en un rincón aislado y oscuro del código anidado, tal como dijo @Charlieface, ¡muchas gracias a todos!