This optimization is portable to other functions. However, there are potential issues with list mutability.
Actually, there could be a way to implement mutability-based optimizations on a scoped basis. This would match languages like Rust, but may be confusing for beginners.
Maybe add this as a parameter for the List constructor? If a hypothetical low-level change was approved, I could implement typed lists: “generic”, “cloning”, and “mutating”. Generic lists would need to be wrapped in the other two types to be usable with most other blocks.
Nice! Can you show a comparison between the fixed version and the original version?... wait, can basic users do this?
i miscalculated the optimizations again, ignore (wrong number of repeats)
Maybe add this as a parameter for the List constructor? If a hypothetical low-level change was approved, I could implement typed lists: “generic”, “cloning”, and “mutating”. Generic lists would need to be wrapped in the other two types to be usable with most other blocks.
The whole point of hybrid lists is that users shouldn't have to think about how the list is stored; it's just a sequence abstraction, and it's the language's job to make sure it's stored efficiently. So I think complicating the LIST constructor would be counterproductive.
(Side note: It strikes me that I keep inventing features with "hybrid" in their names: hybrid lists (long since implemented), hybrid scope (rejected by Jens), hybrid primitives (was on the list for a long time, but recently implemented). I wonder what this says about my psychology.)
Maybe “hybrid” is just a fancy word for getting it both ways, having your cake and eating it, too! 
True enough!
My de-abstraction suggestion doesn’t fit in this project’s scope, so I will reconsider where I apply the concepts of lists.