I ended up implementing a solution where I wrap the destinations in a hashable enum like this: enum NavigationTargetMainWindow: Hashable { case package(BrewPackage) case tap(BrewTap) } And then navigate to them using the value like this: NavigationLink(value: NavigationTargetMainWindow.tap(tap)) { Text(tap.name) if tap.isBeingModified { Text(tap.name) } } This still didn't work properly, so I had to move the navigation selection variable out of my global AppState and into a local @State variable; only then I stopped getting the message "Publishing changes from within view updates is not allowed, this will cause undefined behavior." Another Issue Again Now I'm however running into another issue: I have a .task on the detail view that's supposed to load additional data. This .task only gets triggered on the first load of the detail view, and never again, so the detail retains the stale data. I suppose SwiftUI is trying to be clever and not reconstruct the entire view? I tried using .task(id: package.id), and this does fire the task, but there's a split second where the old view is still visible, which isn't desirable: https://streamable.com/3ucoy9

Thanks a lot for the explanation! I didn't see it in the release notes. I have a related question: Before I start trying to hack something together, is there a recommended way to do this type of value navigation if you can select two completely unrelated types from the list, which in turn navigate to unrelated detail views? In Cork, these are: PackageDetailView, which takes the BrewPackage type TapDetailView, which takes the BrewTap type Until now, this was solved by using the incorrect behavior of defining the destination view inside the NavigationLink: NavigationLink { PackageDetailView(package: package) .id(package.id) } label: { PackageListItem(packageItem: package) } NavigationLink { TapDetailView(tap: tap) .id(tap.id) } label: { Text(tap.name) } In this example, and in other examples I could find, only one type is used.