i agree with you, chrisshwli, since the Apple recommendation was basically "don't do that." let's acknowledge the problem. i would really like a way for a View to access the NavigationPath it's inside of and use it. (in my case, the view we're talking about needs access to the NavigationPath.)

looks like my minimal example actually now has exactly the issue above: works fine when navigated to, but doesn't show the button when presented in a sheet. tried to file a feedback, but Feedback Assistant crashed (really!). not a good day so far.

sorry for not mentioning the context: the code above was run in a simple MacOS command line project.

just realized: ordered(by: { $0.position < $1.position }). (duh!)

i think it would help if more code were available ... if you have it on GitHub, BitBucket, or somewhere else, we could look at it. in particular, i'd like to see the code for the CourseEditView, whether its incoming argument course is held as an @ObservedObject, and how the code handles the optional properties of the course. that alone could be the problem: when a course is deleted, SwiftUI may still have access a CourseEditView involving the deleted course.

i agree with you whole-heartedly when you say "I do think the graph view is crucial for establishing and analyzing relationships." you can get a nice overview of the model from the graphical diagram that otherwise takes a few minutes to flesh out when you have to read through each entity separately and basically sketch out a diagram by hand.