While exploring features of Labeled Section Transclusion Extension, mainly used into source projects as a tool for proofread procedure, I found that the extensione could solve many issues completely unrelated with such procedure, but I found too some liminations coming IMHO from the way it is implemented into the parsing path of the raw text of the page.
1. I can't transclude raw text wrapped into a template call: this doesn't run: {{center|<section begin=1 />Text<section end=1 />}}
2. I can't transclude raw text wrapped into a HTML comment like this: <!--<section begin=1 />Text<section end=1 />-->
3. I can't transclude raw text wrapped into a noinclude tag: <noinclude><section begin=1 />Text<section end=1 /></noinclude>
4. I can't transclude text coming from the same page calling transclusion.
I can't read php parsing scripts, but I can imagine that that thing will change if labeled transclusion would be simply built as a regex search into the raw code of the page, ignoring any other content of such raw code; and I can imagine too that a great improvement in performance should be gained if the page to search in would be kept into memory or into a fast cache, allowing multiple labeled section searches into the same page without the need of reloading it.
If #lst would be converted in a fast, effective, simple code including tool, lots of interesting results should IMHO be gained: templates could be converted into "libraries"; mono-and multidimensional arrays could be easily used; a undetermined number of "variables" could be loaded and used easily; redundance and coherence of data and metadata could be gained. Most interesting, nothing of usual #lst syntax would need a change.
Is there any major drawback in such an idea?
Alex brollo