I feel pretty strongly that dedicated syntax is the right approach here. While you are correct that this increases the implementation complexity, as well as requires more effort from users to learn, crucially IMO both of these costs are one-time; we only need to implement the feature once, and a new user only needs to learn the new syntax a single time. In exchange for these two one-time costs, the syntax will make the behavior easier to read and understand, since it is similar to natural language, and so will quickly pay for the upfront complexity by simplifying actually using the language. You can see this tradeoff in many places in other languages, but the classic example is
I absolutely agree we should add a realistic example to the FLIP. I am by no means an expert on writing smart contracts though; @bluesign would you be willing to help me out by writing such an example and we can add it to the FLIP?
Attaching to resource references
As the language is right now, I don’t think it makes sense to allow this; we want the owner of the resource to have control over who can and cannot add or remove attachments, so allowing anybody with a reference to that resource to be able to modify its attachments seems unwise. If we had a feature like you suggested to limit access to
remove, I’d agree then we could extend those operations to work on references. This IMO is out of scope of the FLIP though. Let’s get the core of the feature out and then we can work on a proposal to add new functionality to references/attachments to make this work.