It's great to hear you enjoyed the articles and thanks for sharing your concerns about the Navigation framework. Let's see if I can allay them.
When writing the MSDN articles I tried to come up with a sample project that demonstrated the different features of the framework in a straightforward way; but I agree with you that it wouldn't be appropriate to build a real online Survey in that way. However,
that doesn't mean the Navigation framework can't still be used. The way to build a real Survey application would be to store the answers, as you say, in Session, but to still use the Navigation framework to handle the forward and back navigation. In that case,
only the previous State(s) would appear in the URL and not the user's data.
I've taken this a stage further in applications I've written by storing the data in Session but still allowing the user to open multiple windows/tabs. The way I've done this is to maintain an id in StateContext Data that points to the specific instance of
the user's data in the Session. Then it's just this id (and previous States) that appears in the URL and not the user's data. That way, you can have multiple instances of the user's data allowing them to complete two surveys simultaneously in different windows.
If you prefer, you can even configure the framework so that the crumb trail is stored in Sesssion rather than the URL or write your own custom crumb trail storage mechanism.
I agree that removing the crumbs is pointless if you want to make use of back navigation. However, there's more to the Navigation framework than back navigation. For example, it's really useful in building Single Page Applications where there's no point
in having the crumbs in the URL.
I hope this gives you the idea that the Navigaiton framework has a lot more about it than I could explain in the articles and I look forward to hearing what you think.