(if we allowed dashes in EViews names, we wouldn't know how to read this line "y minus z::x" or "y-z workfile, series x"?)

In any case, if you specify an EViews name, you shouldn't use dashes. Our COPY method does have some inconsistencies in how it parses the dash, but the overall premise is still correct. If you want to specify the file, use the file extension. If you want to specify the EViews name (and the associated workfile or database is not already open), make sure the internal name matches the filename exactly (no dashes allowed).

The one exception to this rule seems to be database (EDB) names so I'll look into that more. Those seem to allow dashes in the name in the COPY method without any issues. It's possible we could do that same exception for workfiles, but I'm not sure.

In any case, the safest thing to do when writing EViews programs is to avoid using dashes in any of your filenames.

Turns out the exception is the rule. If you don't specify a filename, EViews will default to thinking it's an EViews database (EDB) and will treat it as such. That's why the dash seems to work. If you don't specify a file extension and you don't have a corresponding EDB file in your default directory, the copy operation won't be able to find the workfile.