I do not think there is such a thing as a "debug-only" text representation within the API surface of the Swift stdlib.
I do believe that conforming to CustomStringConvertible is the obvious way for Swift types to provide a custom text representation of their instances -- that is what this protocol is for.
Its relation to LosslessStringConvertible is a second-order matter; but the illustrative description strings in the proposal can indeed be used as the input format for a LosslessStringConvertible conformance for String.Index, if we wanted to add one. (However, I am not planning to add such a conformance; I think it would be a bad idea.)
The @DebugDescription macro does not seem relevant to this proposal -- the macro did not add anything to clarify the semantic distinction between description or debugDescription, and it is able to work with either property.
(Aside: My personal opinion of using this macro in systems contexts remains rather poor; I do not expect String.Index (or any stdlib type) to use it. We're far more likely to either provide hand-written LLDB summary strings, or to continue to maintain data formatters directly in LLDB, like the preexisting String.Index formatter.)
Conforming String.Index to a niche/exotic protocol like TextOutputStreamable would be a non-starter.
(Aside: However, note that TextOutputStreamable does provide a very useful model for streaming descriptions: it allows values to get printed without materializing their full representation all at once in a single String instance. This is exactly what we need in environments where heap allocations do not exist, or are overly expensive. Therefore, there is a good chance that TextOutputStreamable will eventually become the (conceptual) basis for a lower-level CustomStringConvertible alternative in the future. However, even if that future becomes reality at some point, it will not make us regret adding a description property today.)