The problem:
Sample offsetting (the 9 command) is based on a percentage, so as the sample gets larger, your precision gets smaller. This method is inaccurate (and obsolete). A (destructive) process of cutting/pasting is the only solution for byte accurate sample access.
The solution:
Create markers in the sample editor, which can be referenced in a tracker.
Markers can be accessed via a tracker-command, or via the more traditional key map. (depending on what floats your boat). Offsets can be configured to stop at the next marker, or to continue until the sample ends.
This is both non-destructive and easy to manage. Offsets could be automated to match actual transients rather than even spacing.
This has been suggested quite a few times by different people (myself included) using slightly different wording like ‘slices’, ‘markers’, ‘regions’, etc., and there have even been a couple of screenshots made in different threads, but your mockup is one of the clearest and easiest to understand that I’ve seen so far. I also fully agree with the optional behaviour to stop playback before the next slice. Great work, mate
In my particular ideal version of this, it would also be possible to give each individual slice/region/offset its own loop settings, which I often do manually when working with breakbeat loops. I will cut each individual sound out of the drum loop, then apply a pingpong loop to the tail-end portion of each hit (typically the ‘air’ inbetween hits), which then allows me to play the entire loop slower and still maintain the overall air/ambience, rather than having choppy silence between each hit.
Even without individual loops at first, implementing what you have outlined here would be a huge step in the right direction.
I’ve thought about this multiple times too (the command mapped offset idea).
Only problem is there aren’t any commands free anymore. In your example you use 99xx, what happens to the 9th parameter of the 9th device in the DSP chain?
The only solution I can think of is making two different effect columns, one for controlling parameters of dsp’s and one for the sample commands.
A simpler solution proposed in other threads has been to add a ‘sample offset mode’ selector in the instrument properties.
The options would be something like:
256 equally-divided regions mapped to 00-FF
256 user-defined regions mapped to 00-FF
256 user-defined regions mapped to notes
You would choose the appropriate 09xx behaviour for that instrument, and then the 09xx pattern command would remain the same.
This is of course just a quick/temporary suggestion. Most people argue that it should be possible to handle any situation at any time without being limited to one particular mode, but this will require new pattern commands to be created, which itself requires that pattern command identifiers break out of the hexadecimal naming scheme. A lot of this has already been talked about and argued for/against in the past, hehe.
The idea of having ANOTHER column seems crazy (but still feasible I guess!)
What about “0G” (g) as a command? Is hex a necessity? Or something more relevant like “S” or “O (for offset)”. 0G-0Z are still unused if there’s no technical limitations.
Key-mapping is perhaps the way to go in conjuction with a key-transposer metadevice if you want to change pitch (now there’s an interesting idea)
The existing xrni format is more or less the .xi (ft2) instrument format with filters & polyphony/NNA. So the technology is around 15 years old.
It would probably be better if they developed a special API for the instrument format so you can add oscillators + filters/effects - something like SynthEdit for Renoise would be perfect. It’s wishful thinking and maybe too much work.
All this stuff is priority number one for me personally, development wise. Especially the 09xx user definable / NNA stuff, that is my bread and butter!
(now there’s an interesting idea) 
