Thanks Mark, I pretty much agree with everything you said. You’re right that as currently implemented, what I am thinking of is more like a new view. But the differences may go deeper than that and my own ways of putting it and thinking sort of obscured the difference.
The current way that Tinderbox works I’d say is roughly that there is a single large structure of notes with attributes. Each view offers particular affordances in relation to some attributes of the notes in that structure. So the Map view focuses on spatial attributes and renders those visually. Outline view disregards spatial attributes and gives priority to the order attribute and the hierarchy attributes. And so on. The note is the atom and it is its attributes that are fundamental.
(This is one reason that links do not have an independent existence, each is an attribute of a note. This point has come up in past forum discussions where I suggested they might be made “first class” or independent entities because they were themselves a kind of semantic content.)
What I described and which I think the OP described would imply some kind of duplication or overloading of some attributes which would be indexed to a particular view. So map view A on notes p,q,r would show them according to some spatial attributes (e.g. xpos,ypos). Map view B on the same notes p,q,r would show them according to different spatial attributes. But a note can only have one set of spatial attributes at a time in the present implementation. So what is implied for this to work is that note p in fact has a two-dimensional array of spatial attributes roughly like this p:{[A(xpos,ypos)],[B,(xpos,ypos)]} where A and B stand for map views. In fact, it would have an array whose first dimension was as large as the number of relevant views in which it appeared. My point is that this is non-trivial and in a way more than just another view and there is a serious question to answer about which attributes should/could be indexed to views of any kind. (You can see that replicants as used in Devonthnk are there to solve part of this problem because they facilitate the presence of the same entity in more than one containment hierarchy.)
This connects to your well-observed points about PKM software and thinking-assistance software. If you think of Tinderbox as a PKM tool, then the use case I described is probably out of scope. DevonThink seems to me a clear-cut PKM tool: it stores knowledge and facilitates finding, managing and annotating it. Somehow I’ve never really thought of Tinderbox that way, which I know is a personal view, even though it can be thought of that way. Tinderbox’s appeal for me is that it is a kind of “doing” space where you can do things: think with them, think through them, make connections, and create in a surrounding of contextual content. To make a crude analogy, Tinderbox can be in thought like one of those exoskeletons that people can wear to enhance their strength, reduce their fatigue, even increase their reach.
At any rate, that is a kind of personal hope for Tinderbox (and I am not aware of any other software close to doing what TB does). I’m a second-rate user of TB compared to some people on the forum and its first appeal to me was that it reminded me of Hypercard because of how one could “automate” notes. Hypercard was great but was still mainly, in my view, about traversing a body of content with some dynamism in the content and the traversal. Tinderbox can do that, but seems to me also to hold out the promise of augmenting the thinking about that content.