Consider the following trivial patch (testing on Pd 0.45.4 on Ubuntu 14.04):

In it, I have a [pd mysubpatch A]. As far as I remember, the A is now an argument of/to the subpatch, in particular it is the first argument - and references to $1 inside the subpatch should expand to A.

So, I've decided to place an array inside the subpatch, and call it $1-array, similar to how in abstractions, arrays are/can be called $0-array - except there the $0 doesn't expand to any arguments, but instead expands to a random number (Dollar signs in objects and messages | PURE DATA forum~). My expectation is that the $1 in my case would expand to the first argument, A, and thus the array name at instantiation time of the object [pd mysubpatch A] would expand to A-array.

The idea is thus to be able to put multiple subpatches in a patch, and control their internal arrays' names by supplying unique arguments. So, I try to copy/duplicate the [pd mysubpatch A] into a [pd mysubpatch B], expecting its array would ultimately be called B-array. So far so good, because I can do this without any problems.

Now consider a slightly more complicated case where I also have a tabwrite~ in the subpatch:

Now that I have [tabwrite~ $1-array] referencing the $1-array in the subpatch, as soon as I turn on DSP/audio, I get a ton of warning: $1-array: multiply defined messages. As I don't get this message when I have only the $1-array in the subpatch, I'm assuming it is not the logic in naming the arrays $1-array via subpatch arguments that is the problem, but instead it is the reference in the [tabwrite~ $1-array] which is causing the warning message.

Note that exactly the same happens, if I save the subpatch as an abstraction mysubpatch.pd, and use it as two objects [pd mysubpatch.pd A] and [pd mysubpatch.pd B]:

But then, in this case, how would I reference such a subpatch/abstraction array, named through an argument, from inside the subpatch/abstraction itself? Note that I need fixed, explicit, known names of arrays, so a workaround like $0-$1-array wouldn't work for me, since the $0 would expand to a random number, which I in principle do not know from the outside (and I'm not sure $0 even applies to subpatches).

It seems to me that you are confusing the difference between a subpatch and an abstraction. A subpatch is a space-saving device that you create with the [pd] object. Creation arguments ($1 $2 etc.) won't work inside a subpatch; if you reference them, you'll get the creation arguments of the parent canvas, if any. If there are none, then $1 or $2 will just give 0, which is probably why you're getting the multiple defined array error message.

An abstraction is a unique object that can take creation arguments. You have done the right thing by saving it as a pd file "mysubpatch.pd" in the same directory, but to initiate it you just need to create the object [mysubpatch]. If you create [pd mysubpatch.pd], as you have reported above, then you will get a subpatch, which is not the same thing.

Many thanks for the prompt answer, @LiamG:

@LiamG said:

It seems to me that you are confusing the difference between a subpatch and an abstraction.

Indeed I was - many thanks for the great explanation, it was exactly what I needed!

An abstraction is a unique object that can take creation arguments. You have done the right thing by saving it as a pd file "mysubpatch.pd" in the same directory, but to initiate it you just need to create the object [mysubpatch]. If you create [pd mysubpatch.pd], as you have reported above, then you will get a subpatch, which is not the same thing.

I cannot believe I had forgotten this, even if just last year I was doing patches with abstractions :) Great to have this as reference, for the next time it happens :)

Anyways - indeed, it works great - once the (sub)patch is loaded as an abstraction proper, then the patch "sleeps" (as in, no reported warnings), even with DSP on and two abstractions (and even the window title bar tells you that the abstraction now sees argument (A)):

Great to have this solved - thanks again, cheers!

An easier way to get around this is to use $0 inside your abstraction. If you name the array of the abstraction "$0-array", each array of each instance of the abstraction will replace $0 with a unique number (for example, the first abstraction will get 1003, or something, so its array will be named "1003-array", the second abstraction will get "1007-array" and so on).
This way you don't need to use arguments to avoid name clashes with the arrays. Except if you need to have access to the array's elements from outside each abstraction, in which case your approach is easier.