Do you have documentation or a sample model to demonstrate the new syntax?

EDIT: Never mind, I figured it out from the test cases you wrote.

@kgmt0 I played around with it for a bit, and so far I like the way it works and it seems very promising! Here are some issues I noticed:

1. If you import a library and then just use its name without the colon and a command after it, the error message is "Nothing named xyz has been defined." I would expect it to be something along the lines of "xyz is a library, not a command."
2. Imported libraries don't show up under the Included Files dropdown. This is probably up for debate but personally I would like it if they showed up there so I could easily open them.
3. alias is used like a keyword as far as I can tell, but the compiler does not identify it as a keyword. This means that it isn't green and bolded like __includes or libraries, and you can use alias as an alias.
4. Including a library in itself causes infinite recursion and the app freezes. This should be caught before it happens and a relevant error should be thrown.
5. Included libraries are not private to the file in which they are included, which seems undesirable to me. For example, if I include library test in the Code tab, and I include library test2 in library test, I can now access library test2 from the Code tab.
6. No error is thrown if you include the same library twice. Similarly, no error is thrown if you include a library once, and then include a different library that is aliased to the same name as the first library. This latter case is problematic, because both libraries are then included, and any command name conflicts become ambiguous. After messing around with it, I discovered that in that case, the version of the command from the first included library is used, and all other commands with the same name are silently ignored.

Let me know if I need to clarify anything I said.

Thanks for testing!

1. If you import a library and then just use its name without the colon and a command after it, the error message is "Nothing named xyz has been defined." I would expect it to be something along the lines of "xyz is a library, not a command."

Hmm. I didn't consider having a special error message for that because libraries are not (currently) a value, but I can see how users would find it helpful. Would love to hear what other people think as well.

2. Imported libraries don't show up under the Included Files dropdown. This is probably up for debate but personally I would like it if they showed up there so I could easily open them.

I agree. I plan to implement this but haven't got to it yet.

3. alias is used like a keyword as far as I can tell, but the compiler does not identify it as a keyword. This means that it isn't green and bolded like __includes or libraries, and you can use alias as an alias.

It's a bit different from other keywords because it only has a special meaning within the context of the libraries syntax. There's no problem if the user wants to name something "alias", or even use the word "alias" as an alias.

4. Including a library in itself causes infinite recursion and the app freezes. This should be caught before it happens and a relevant error should be thrown.

Good catch! I'll fix that.

5. Included libraries are not private to the file in which they are included, which seems undesirable to me. For example, if I include library test in the Code tab, and I include library test2 in library test, I can now access library test2 from the Code tab.

There's a (not yet implemented) define-libraries syntax that you'll be able to use to list exactly the symbols you want to export. Once that's implemented, I plan to make symbols private by default.

6. No error is thrown if you include the same library twice. Similarly, no error is thrown if you include a library once, and then include a different library that is aliased to the same name as the first library. This latter case is problematic, because both libraries are then included, and any command name conflicts become ambiguous. After messing around with it, I discovered that in that case, the version of the command from the first included library is used, and all other commands with the same name are silently ignored.

Good point. I'll add some checks for that.

Do you have documentation or a sample model to demonstrate the new syntax?

I sent you a link to the design document on Slack.