Your #1 is incorrect. // and /**/ comments are allowed in the class body outside of member implementations. They won't be associated with a class member as a description. They are saved in the system global as part of the class though. They're technically their own class member type called UDLText, which you can see in the XML snippet in the original post.

Hi @Colin Brough, I'm happy to expand on my previous comments.

  1. Yes, this is correct. Exporting a class retrieves whatever is in the system global for that class and builds the text file from it. The serialization happens when the class is imported. That space must be added when the text of the class is converted to the global structure. Therefore, if you manually changed the system global to remove the space it would not show up in the export. NOTE: Please don't actually do that!
  2. Yes, this is correct. Any server functions that export code that export code in a specific format (UDL for VS Code and $SYSTEM.OBJ.ExportUDL() for example) use the same code for performing the export.
  3. The serialization I mentioned in #1 and on GitHub only happens when importing a class in UDL format (the format used for editing in Studio and VS Code), NOT XML. The space must have been removed when someone modified an XML export file directly and then re-imported it.
  4. This won't work for the reason I mentioned in #3.
  5. You could use VS Code to do this. Assuming you have a local folder containing your code open in VS Code, you can right-click on the folder and select the Import and Compile option. This will load all the files in the folder onto the server, compile them, and then refresh the local copies.

The two new apps (Production Configuration and DTL Editor) are opt-in at this time. You must open a Production or DTL in the old app, and then click the "Try the new UI" button to launch the new one. There is currently no way to set the new ones as a default like the Rule Editor since these are still in the early stages, but you can always bookmark them through your browser.

Hi Michael, I am convinced that a change should be made here. I'm going to always enable the code that fills in the ROUTINE and Class headers when a new file is created, because that scaffolding is valuable even if the user has to edit the generated name. However, I will leave the code that modifies existing files when they are moved guarded by the objectscript.autoAdjustName setting, which will remain false by default.