Use case: our app receives data-only FCM pushes ("X followed you", chat messages). The user taps one while the app is killed. The tap should open the target screen with a working back stack.

There is no supported way to do this through the linking layer today. A notification tap launches the app with no URL. In bare React Navigation the documented fix is to customize linking.getInitialURL to await messaging().getInitialNotification() and return the target path, so the tap builds initial navigation state. Expo Router owns the linking prop and hardcodes getInitialURL; when there is no URL it substitutes the root URL. The comment next to that fallback in expo-router/build/link/linking.js says it directly:

// The path will be nullish in bare apps when the app is launched from the home screen.

// TODO(EvanBacon): define some policy around notifications.

redirectSystemPath in +native-intent only rewrites a path that already exists, so it cannot fill this in.

The workaround everyone lands on is dispatching imperatively (router.push inside the notification-open handler). On a cold start that dispatch can fire inside the window where nested navigators have not yet registered into the container. The action then resolves against a bare root and stacks a second copy of the entire app: no back button, dead swipe-back, user stranded. Deterministic for us in a release build. We now hold the route and poll getRootState() until the shell is registered, which works but should not be app code. Related upstream ask: react-navigation/react-navigation discussion #13264.

Request: an officially supported +native-intent hook for the no-URL launch, for example an async getInitialPath() (or calling redirectSystemPath with a null path and accepting a returned one), so a notification tap can resolve its target and enter through initial state like any other deep link. Ideally it only delays first render when the launch actually came from a notification.