The term used for this (in other languages) is "array slicing". (Rust and Python have slices.)
Having thought about this in the past, I'm worried about questions of semantics of slices on mutable contents. It feels sketchy and confusing.
>> data: "abcd"
>> stuff: slice data 2 2 ; position length
>> clear data
>> append stuff "x"
>> append stuff "y"
We don't have Rust's luxury here of having a borrow checker to make temporary slices that hold locks on data, and then release it.
In Rust's world, you can ensure there aren't mutating references to an array extant...make a slice and work with it...then have that slice released so you can pass a mutating reference around. That's cool.
To do that we'd need some kind of
make-slice that took a hold, and
destroy-slice that released it. How to do that cleanly falls under the general question of how to bracket the lifetime of an "iterating" construct. (Please share your thoughts on the critical post: "Modifying While Iterating: Crash, Nonsense, Predictable, or Illegal")
(It could hold a lock on length changes, as opposed to element mutations.)
I'm not sure what Python does, I guess it wouldn't hurt to check.
python: import numpy
python: a = numpy.array([10,20,30,40,50])
python: s = a[2:4]
python: numpy.resize(a, 2)
python: s = 77
python: numpy.resize(a, 5)
Er, okay, well...whatever. We'll assume it's a data blob they're refcounting. Typical Python as "doesn't crash, someone might think that's useful, won't win any awards for design innovation or rigor."
I think resizing is an anomaly in their arrays, whereas it's foundational to series.
I'm Skeptical, Especially if it's Not Rendered Concretely
I already think the hidden index in series is something that needs to be handled more carefully and in people's awareness. I've written about the fact that sticking it in the series is a weird trick that doesn't really offer anything at a foundational level a separate index does not.
This would exacerbate that problem, to hold something in your hand that looks like a simple string but has all these trapdoors.
Were we to try this, one mechanical thing that won't work is adding a second number in series cells where the INDEX is. There's simply not enough room...all the slots are used up.
You cause a lot of problems if you pretend you have room, by making a memory allocation with two integers in it, and put a pointer to it where the index was before. Then you're GC'ing these pairs implicitly without user involvement as they increment and decrement, and chewing up all available memory during a FOR-NEXT.
(Note: This is the same reason that series indices shouldn't be bignums, and should remain constrained as platform integers.)
I'm not opposed to trying something for the sake of being able to avoid having /PART refinements on everything. But I'd like to see hard cases fleshed out first from a user perspective.