1. It relies on later stages to do things like convert to native values or remove whitespace. As such an intermediary can't really "understand" the document very well. E.g., if you are using this syntax to express key/value then you can only know the keys if you know the whitespace rules that will be used to interpret the keys.
2. It reminds me more of XML than S-Expressions. If you are familiar with the ElementTree [1] representation of XML then these parsed examples become more familiar, just a prefix instead of suffix, and no attribute children.
3. Connecting whitespace and XML, I suppose this explains why so many XML formats ended up only using attributes for text values, and used tags and children only for nesting. Otherwise interpretation requires understanding how to interpret these mixed documents with unclear whitespace rules. But Jevko doesn't have attributes.
4. If an intermediary can't understand it then why define a syntax at all?
5. I don't see any escaping rules so including literal [] seems... impossible? You can essentially deserialize the parsed value to reintroduce them, but that's weird and awkward, and only works with balanced brackets anyway.
6. No way to embed binary data, or otherwise uninterpreted data. JSON has the same problem. Base64 encoding things is yet another way in which the data is not interpretable by intermediaries.
I think XML shows that "just strings" isn't fatal, and lots of things get jammed into strings in JSON too, you'll never be able to reproduce every type in a general purpose serialization format (I guess XML with namespaces attempted, but also clearly failed). So I can see a place for something that defines a tree where all leaves are strings. But this doesn't seem like a very clean way to do that.
[1] https://docs.python.org/3/library/xml.etree.elementtree.html...