Jorge it actually sounds like we use repeaters pretty much the same way. And you’re right that in my working Panes, I would have completes hidden so even if the previously-completed instances were children of the parent and therefore mixed-in with the current instance’s children, I wouldn’t see them. Maybe it’d be worth implementing in beta and letting us play with it to see how it actually “feels” in reality?
Thinking about this more, one disadvantage of keeping all completed instances at the same level as the repeater is that an unrelated item can be dropped after the repeater while working with the Outline. The historical repeater items would likely be hidden at that time, thus the stray item would get inserted to the top of the list of completes, which could ‘break’ the history function or at the very least make a mess. This is also possible with the as-children approach, but less likely.
I’m beginning to think the only truly robust approach to keeping a history of competed repeaters is for them to go to a “protected” place. Otherwise there is always a chance to corrupt, destroy, or just make that history messy. I don’t think it’s good for us, for Jay, or for the App’s success to implement this as a kludge of existing features cobbled into something that sorta-works but just spawns a raft of new problems and bugs.
What about leveraging the current Archive feature? I never see people talk about using it, which makes me wonder how much use it really gets. Archiving has an important problem: you can unknowingly blow away archived items (or whole branches) if they are between non-archived items in the Outline and you multi-select, then delete those non-archive items. Depending on your work style, this can be rather easy to do. For a feature called “archive”, this is a serious flaw that prevents me from using it at all. I’ve often felt it should be removed wholesale … or transmogrified into a different, more helpful feature. This might be exactly that thing?
