All you have to do is pick an existing parser that works well and map the output AST to Optic's AST. I'm exploring building an Antlr extension so any grammar in their library could output in Optic's AST but that's still not implemented. Every AST have a notion of type, range, and properties which can either be primitives, arrays of child nodes, or individual child nodes. We have Python and Ruby on our roadmap for the next couple of weeks.

1. We've been exploring migrating one Optic skill to a newer version. So far it seems promising for the cases you'd expect a code-mod to help with, but if you completely change the API and deprecate some stuff it can point out the changes but won't be able to help you -- no magic here.

2. I looked into language servers (lsp) but the implementation was a lot more involved and I found bugs in some of the IDEs that claim to have full lsp support. As the protocol matures and we add more functionality to Optic I expect to see lsp become our main avenue for IDE/Optic interactions.

3. We wanted to make it really natural to ask Optic a question. We thought '///' would be unique and easy to remember, but we're open to changing it. It's nice that '///' also evaluates as a comment too because before we used it sometimes characters in your search would cause the AST parse to fail. We're open to any ideas here -- a lot of users have said it's funky.