"readme.txt" is still shell code. Most shells will evaluate it to the string "readme.txt", but scp on the client should not make assumptions of the shell used on the server.
If you write:
scp server:'*.txt(oc[1,10])' .
A server that's setup with zsh with extended globs is going to return the newest 10 .txt files. If scp is written with an expectation of basic globs, I imagine it would try to match the files that have a character-by-character literal extension of ".txt(oc[1,10])". That means no file is ever going to match. You could say, "well, add recognition of zsh extended globs". Ignoring how complicated that really is because there are glob options that allow you to embed arbitrary zsh code, you're limiting the implementation of scp to work with only particular shells. scp should not be a barrier to me implementing my own shell, with it's own syntax and using it transparently. The current scp doesn't care about what shells you use where. It makes little to no assumptions of the tools you use, and that's cool.
Well the language scp uses for selecting files is turing complete and relies on state unavailable to the client therefore it is impossible in the general case for the client to check whether a given file sent by the server was actually requested by itself. That's the langsec failure here. The "correct" (in any case more sane) approach would be to use a stateless, easily recognizable language for specifying files (e.g. something that reduces to REs).
And that's what I meant by saying that I couldn't see what else to do without sacrificing usability. Whatever that language you propose would be, if it doesn't allow use of state from the server, then it's pointless. You may as well use the local shell in scp's invocation.
If you write:
A server that's setup with zsh with extended globs is going to return the newest 10 .txt files. If scp is written with an expectation of basic globs, I imagine it would try to match the files that have a character-by-character literal extension of ".txt(oc[1,10])". That means no file is ever going to match. You could say, "well, add recognition of zsh extended globs". Ignoring how complicated that really is because there are glob options that allow you to embed arbitrary zsh code, you're limiting the implementation of scp to work with only particular shells. scp should not be a barrier to me implementing my own shell, with it's own syntax and using it transparently. The current scp doesn't care about what shells you use where. It makes little to no assumptions of the tools you use, and that's cool.