The order for searching for beginning of a block or line comment cannot be determined by the order of block/line comment definition in syntax highlighting wordfile. So it is important that a line comment is not just a substring of a block comment starting with same character(s).

It is necessary to write line comments in files to syntax highlight with UltraEdit always with a semicolon and a space and use this definition in wordfile:
Note: There are exactly two spaces after 2; in above line.

A semicolon is interpreted as beginning of a line comment with this definition if a space follows and there is no slash left to the semicolon.

I suggest following:
There is absolutely no possibility to force UltraEdit to evaluate the first character after a comment starting string to determine if that string really starts a comment and which type of comment as it would be required for LUA and Papyrus (and one more language on remembering correct from more than 650 supported languages). UltraEdit supports nearly all languages ever invented by someone, but not all languages and some not in all aspects.

The definition above adds a second line comment definition for interpreting just ; as line comment starting string only in first column in a line. Of course a block comment starting with ;/ also at column 1 of a line results in getting just this line syntax highlighted as line comment and not as beginning of a line comment  and everything else up to /; because of UltraEdit does not evaluate / after line comment starting string ; to find out that this is not a line comment (but a block comment).

It would be also possible to save into a macro file a macro with following macro code and configure this macro to be automatically executed on every file load:
The file extension psc is interpreted case insensitive by UltraEdit. This macro executed on every load of a file results in inserting a space character after every semicolon if the file has the file extension psc and there is neither a slash character left to the semicolon nor a space or slash right to the semicolon.

/Strip Comments = No disables stripping line and block comments from file content in memory before running the regular expression search(es) for the strings to display in function list since UltraEdit for Windows v24.20.0.35, see Function list ignores block comments ... could this be optional?

I modified also the Perl regular expression. /s matches any whitespace according to Unicode which includes the newline and vertical whitespace characters carriage return and line feed and so every Perl regular expression starting with ^\s* matches also empty and blank lines. That is usually not wanted for functions to show in function list because the line number should be the line number containing the keyword function and not the line number of an empty or blank line above. And I suppose that Papyrus is like most programming and scripting languages and interpret only the ASCII whitespace characters normal space, horizontal tab, carriage return and line feed as horizontal and vertical whitespace characters and not all whitespace characters according to Unicode. See also Remove / delete blank and empty lines.

I assume also that a function name cannot contain any word character according to Unicode for being valid for Papyrus. I think supported are only the ASCII characters 0.-9A-Za-z_ whereby a regular expression in a wordfile is always executed by UltraEdit case insensitive and therefore it is valid and more optimized to skip A-Z from this character class. Unicode defines thousands of characters as Unicode characters. So using a character class containing the word characters really supported by the programming or scripting language avoids false positives and decreases time required to complete the searches.

And last .* at end (or beginning) of a search expression is not optimal. It is not clearly defined where to end (or begin) matching zero or more characters. In theory .* at end of a search expression can result in a positive match if no character is matched/selected at all. But Perl regular expression engine interprets .* greedy per definition and for that reason it matches as much characters as possible which means all characters except newline characters (or end of file depending on a flag controlling matching behavior of dot). For that reason I appended $ to specify clearly where to stop matching any character except newline characters zero or more times greedy.

You do a quite good job as beginner on using UltraEdit. I am really impressed.

Following macro code worked on my tests on opening a *.psc file:
The two IfFound are just for safety reasons to avoid further execution of macro commands on one of the two strings not found case sensitive in the just opened *.psc file.

The optimized version using just following code does not work on file load while working on manual execution after file load.
I think, the reason is that the macro is executed on file content before syntax highlighting is applied at all and therefore the open/close fold string definitions are not available on execution of the macro. Parsing a file for code folding is done in background after file open finished already being important on opening a very large file with millions of lines.

For that reason it is necessary to really select the block to fold which is done with the two Find commands. The second Find command is with option Select resulting in extending the selection done by first find to end of found string of second find. That's like holding key SHIFT while clicking in Find and Replace window on tab Find on button Next.

I am not an employee of IDM Computer Solutions, Inc. I am just an UltraEdit user. So I don't know anything about planned extensions. But I doubt that a native plug-in interface (DLL interface) is planned by IDM Computer Solutions, Inc. The UltraEdit macro and script environments are designed for automatic editing tasks on files opened in UltraEdit or UEStudio. There are lots of scripting languages available to do other things with files and folders. All those script interpreters supporting direct access to files and folders or other resources of operating system are potentially dangerous as scripts can be written by everyone using those script interpreters to do something harmful.

It is possible to configure a user tool to run a script interpreter with a customized script file for a specific task which cannot be done in UltraEdit or UEStudio. Such user configured user tools can be executed from within UltraEdit macros and scripts. It is even possible to configure a batch file or another script file or an interpreter executable as user tool which executes one or more scripting commands created dynamically in an UltraEdit script or macro.

The posted code for the macro executed on every file load works in my configuration.
Please verify in dialog window Set Macro to Run on File Load/Save:

1. The macro file name configured for Macro filename;
2. the macro name entered for Macro name to run on load;
3. 1 is set for # of times.

If the fold is still not working on file load, please write one more post with following information and files packed into a 7-Zip, RAR or ZIP file attached to the post:

1. The lines as stored in INI file of UltraEdit in section [MacroLoadOS];
2. how all code folding settings are configured by you in configuration;
3. how a *.psc file is usually opened by you,
4. the version of UltraEdit used by you;
5. the *.uew wordfile used by you for syntax highlighting *.psc files;
6. the *.mac macro file containing the macro executed once on every file load;
7. a small example *.psc file.