Ok. Yes, then we are basically talking about the same things here. This is like my first option I wrote about.
The patterns and thus the matrix is dividing and representing the data that is there. No matter if it is a clip that has “generated”/inputed the data.
It doesn’t need to know there is a clip system at all.
We just need some rules for what should happen and how to visualize things that are reused/linked (either pattern or clip).
The clip pool is basically just a separate pool of clip data that is not necessarily stored in any pattern.
How these clips are created is another story and not so important in this discussion( but I wrote some thoughts about that in this ancient post.It’s about clips being automatically made, and using tagging and smart sorting filters to keep control of them.
A clip can also be a audio clip, and perhaps automation clip and fx clip or whatever we find useful divided into separate clips.
Anyway, a separate clip system or not, a better way to move data between patterns is much needed. No need to thing about clips to do that.
Like danoise has pointed out very well about the ‘Improved “continuous” mode’ in the Zoomable pattern thread.
Also the post I wrote about pattern data being automatically and temporary bundled for easier handling (as you also linked to) is just another example of several ‘arranging tools’ coexisting.
So yes, I agree with you. The patterns we have now should not limit us in any way. It should adapt to us, and not the other way around.