Sorry, I talked too much and obfuscated my point, I guess. Of course you can add a separator, if you wish. And it's fine to have a "feature" that a directory is a fully qualified path.
The "misbehavior." regards the FiJI scripting editor // @File(label = "Input Directory", style = "directory") input NOT returning a path that includes the separator on the end out of the box when this IS the default behavior of getFileList(). It is the inconsistency that matters. Folder object should either ALWAYS or NEVER contain a file separator at the end.
I was imagining (perhaps incorrectly) that the reason the scripting editor failed to do so for the the // @File(label = "Input Directory", style = "directory") directive was that somewhere in the code a "\" and not a "\\" was used for Windows. [This is common code mistake for those that must deal with the backslash way of writing paths] If the scripting editor directive fails to supplied a terminal directory separator on Linux as well, it just means Linux is inconsistent as well. In that case, the title of my post can be written "Fiji Scripting directive misbehaves on Windows and Linux (and probably Mac OS).
When one switchs from running the code in the editor to running it standalone, you'd like all folder endings passed from elsewhere to appear consistently without having to do an endsWith('"\") || endsWith('/") test when constructing derivative paths..
Of course, if it is a "feature" for the scripting editor // @File(label = "Input Directory", style = "directory") directive to fail to supply supply a terminating directory separator, it would be interesting to know how I would be able to benefit from such a feature.
Talked too much again, didn't I?
Summary: "good behavior" means scripting directive behavior should mirror getFileList(). behavior in supplying terminal directory separator.