AppNotificationManager.Default.Show(toast) returns, Register() succeeded, Setting reads Enabled — and no banner ever appears. Nothing threw, because nothing is wrong with your call: Windows accepted a notification for an app it will not toast for.

Toasts are addressed to an app identity, the AppUserModelID. A packaged app has one from its MSIX; an unpackaged WinUI or MAUI build only has whatever the Windows App SDK registers on the fly, and the shell can decline to show banners for it. The fix is identity, not code: package the app as MSIX, or install it with a Start-menu shortcut that carries an explicit AppUserModelID. Nothing inside ShowAsync changes.

The error

There is no exception to paste. The evidence is the honest frame from the build log (abridged):

Register() succeeds. Setting == Enabled ("Allowed" on screen). Show() returns.
The AUMID {GUID} is registered with DisplayName + icon — and no banner.
Moved Register() to OnLaunched (the documented rule for unpackaged apps): still nothing.
A toast sent to THAT AUMID from PowerShell's WinRT API is silent too, while
PowerShell's own AUMID banners fine — the OS is suppressing this identity, not our code.

Why it happens

The Windows App SDK supports unpackaged apps by registering an identity for the exe — a generated AUMID — when you call Register(). Registration can succeed, the per-app notification setting can read Enabled, and the shell can still decide not to render a banner for an identity that arrived that way. Which unpackaged builds it happens to is not documented; ClinicLive's plain-folder debug build was one. The API has no return value for "accepted and dropped".

The diagnostic that separates "my code" from "my identity": send a toast to the same AppUserModelID from another process. If PowerShell's WinRT call to your AUMID is silent while its own AUMID banners, your code was never the problem.

The fix

Keep the registration where the docs want it — before the first window — and know it is necessary, not sufficient:

// Platforms/Windows/App.xaml.cs
protected override void OnLaunched(LaunchActivatedEventArgs args)
{
    // Register for notifications before the first window exists, as the docs
    // ask. Honest status (Part 5, unchanged through Part 11): this did NOT make
    // toasts appear. Registration succeeds, Setting == Enabled, Show() returns —
    // and no banner is displayed. The cause is app identity: this build is
    // unpackaged (no MSIX, no shortcut AUMID). See docs/pocket.md.
    AppNotificationManager.Default.Register();
    base.OnLaunched(args);
}

Then give the app an identity. Packaging is the documented path:

dotnet build src/ClinicLive.Pocket -f net10.0-windows10.0.19041.0 -c Release `
  -p:WindowsPackageType=MSIX -p:GenerateAppxPackageOnBuild=true

Sideloading that package means trusting a certificate on the machine, and producing a sideloadable MSIX from the CLI alone reported success without an installable package — Visual Studio's Package-and-Publish wizard drives the targets that do. The alternative for a plain-folder install is an installer that creates a Start-menu shortcut with an explicit AppUserModelID, and registering under that same id.

Where it bit us

Season three, Part 5 (tag pocket-05 in the repo), where the Android notifications worked and the Windows ones did not; Part 10 named identity as the cause; Part 11 built the MSIX and stopped short of the certificate. Commit 1e4a67c, "Tell the truth in the Windows notification comment", is the honest close: this one stayed open for the season. The lesson is to say so, in the code, rather than let a comment claim a fix that a screenshot never showed.

Frequently asked

Why does AppNotificationManager.Show display nothing in an unpackaged app?
Windows toasts are delivered to an app identity, the AppUserModelID. An unpackaged build has only the temporary identity the Windows App SDK registers at runtime, and the shell may accept the notification and never render a banner for it. Registration succeeding and Setting reading Enabled do not guarantee a banner.
How can I tell whether the problem is my code or the app identity?
Send a toast to the same AppUserModelID from PowerShell using the WinRT ToastNotificationManager. If that is silent while a toast to PowerShell's own identity appears, the operating system is suppressing your identity and no change to your Show() call will help.
Does calling Register() in OnLaunched fix silent toasts?
It is required for unpackaged apps and it must run before the first window, but it is not sufficient. In ClinicLive Pocket it succeeded and toasts stayed invisible. The fix is a real identity from MSIX packaging or a Start-menu shortcut with an explicit AppUserModelID.

More decoded errors in the Fixes category; the app this came from starts at From Prompt to Pocket, Part 1.