As Eric suggests, there should be nothing special about `LiteralString`.
The PEP doesn't say it so clearly, but I think it's just the case that every `Literal[expr]` type where expr has type `str` is a subtype of `LiteralString`, and `LiteralString` is a subtype of `str`. Everything else is a consequence.
The issue with the list literals is a general issue with collection literals, not about LiteralString specifically. A list literal where the elements all have type T can actually have type `list[S]` for all types `S` s.t. T is a consistent subtype of S. So `['foo', 'bar']` can have type `list[Literal['foo'] | Literal['bar']]` and also `list[LiteralString]` and `list[str]` and `list[str | bytes]` and `list[Iterable[Any]]` and `list[object]`, etc. That is, ['foo', 'bar'] might be a list of objects that just happens to currently contain only strings.
But once you determine a type for that value, it cannot change. If you determine it's a list[object] then someone might put an int or something in it and you can't later say that it's actually a list of literal strings. And if you determine that it's a list[LiteralString] then that necessarily prevents it being used as a list[object].
Eric mentions bidirectional type inference, and that's something that you could try. If you do it for literals as you suggest, it will be "easy". If you do it for variables like `xs = ['foo']; ... xs ...` then you will have to find some way to consider all the contexts that `xs` occurs in.
Another idea that seems similar to bidirectional inference (I think) is to treat the type of ['foo', 'bar'] as involving an unknown type that is bounded by a subtype: list[Unknown > Literal['foo'] | Literal['bar']]. Then when you generate consistent subtype constraints for your example of couple(['foo'], [s]) you would have constraints:
list[Unknown > Literal['foo']] < T
list[str] < T
And because `list` is invariant then you have a consistency ("equality) constraint that (Unknown > Literal['foo']) = str which you can solve by str.