Are include file named parameters positional?

I am not seeing it. When I compile and run on 12.2 it generates the expected output:

Buffer buffer Copy copy

Adding additional messages in test.p, test-1.i, and test-2.i shows that the include parameters are as expected.

I made a slight change to test-1.i. Although, it had the same result with my version (11.5). Odd.

In 11.7.5 the message I see is "Buffer Copy &buffer=buffer".

Adding a " &GLOBAL-DEFINE copy . " to the top of test.p gives a more expected "Buffer buffer Copy ."

Seems the preprocessor messes up when you try to pass an undefined preprocessor into a named argument, and treats the next token as the value to be passed in.

Kind of throws a monkey wrench into what I'm trying to do. I would love to know if this is by design.

Maybe if you could explain what you are trying to do, someone might be able to help with a better solution. 

James, I am working with legacy code. And the example is pretty much that. I have a dataset include that contains a temp-table include that needs to be compiled passing named arguments - to add flexibility.

hi,

  what happens if you change a little

{test-2.i &copy2={&copy} &buffer2={&buffer}} <-- Skips buffer, putting buffer in copy instead

test-2.i

message "Buffer" "{&buffer2}" "Copy" "{&copy2}" view-as alert-box.

To answer the titular question...  No.  You can have either named or positional arguments but named arguments are not secretly positional.

It has been several decades since I did much with named arguments to include files but I do recall that being very careful about quoting strings properly at each level of a multi-level chain of includes was always very tricky.  And thinking about what is needed (or not needed) for quoting at each level gets messy too.

I tested your example back to 10.2B and it behaves the same so your issue does not seem to be a newly broken sort of thing.  I think it is more of a misunderstanding regarding how an undefined argument value, the first reference to {&copy}, gets handled or possibly just how the tokens are parsed.  You might find this subtle (note the extra spaces around "=") variation interesting to consider:

/* test.p  

*/

{test-1.i &buffer = buffer}

quit.

====

/* test-1.i

*/

{test-2.i &copy = {&copy} &buffer = {&buffer}}

====

/* test-2.i

*/

message "Buffer" "{&buffer}" "Copy" "{&copy}" view-as alert-box.

If it is legacy code then there are probably lots of existing examples of the particular thing that you are trying to do.  And if there are not then it seems like this would be an excellent opportunity to introduce a better way of doing things.