I've found the 'same' (abstract) gripe in related fields: for example, PostgreSQL allows users to extend the language with custom operators that must be composed from multiple punctuation marks; the intended use is so you can write succinct formula-like operations like `case when my_container <@ my_elements then ...` or `set participants = applicants <&&> employees` and so on. The problem with these of course is that it's often very hard to guess what some kind of !!`#+*@ semantics a given grawlix is intended to have; both `case when is_subset_of( my_elements, my_container ) then ...` and `set participants = union_of( applicants, employees )` are much clearer.
Another example are customized extensions of MarkDown syntax. To my mind constructs like `[link title](like_address)` already stretch things and the only justification for having brackets plus parentheses to stand in for link syntax is their ubiquity. One of the downsides of this terse syntax is its resilience to extensibility. For example, when you start with an exclamation mark as in `` now all of a sudden your code is understood as an `<img>` tag, not an `<a>` tag. What if you need extra attributes? There have been multiple suggestions how to extend `` to include desired image dimensions, none have become standard. You probably should fall back to inserting HTML, which I am fine with.
Lastly, when designing a user interface, I have found that having to choose icons is a significant burden, and often one without satisfactory solution. One of my solutions in the past was to fall back to Apollo-era text-only buttons; sure, the texts would have to be localized, but then the entire application is subject to localization anyway. A plus is that each button with a short text instead of a picture already provided the mnemonic, the identifier for that action, something an icon does not do for you.
