I'm not sure if that's a good idea. All scripts that use the target path would have to be checked and adapted if necessary. Does e.g. prodloc still work?

Good point, I hadn't thought of the other scripts. I have now searched for mentions of gbuild in the code, and the only script I can find that references it is pcsn, which apparently copies a single file to the correct place in the target. It even has an -n option to copy the NC version of a geode, but it looks to be hardcoded to the gbuild path for both NC and EC.

However, it is currently not functional because it depends on a file in Tools/build/product/Ark/ark.filetree that does not exist in the repo any more. Let's see if I can get it to work again...

prodLoc looks fine at first glance because it gets all its pathnames from the command line.

Ok, but then the call to prodloc must be adapted in the build process. Are you sure that's all?
My experience is that you can never be completely sure with such interventions in the concept (never touch a running system :).
And of course I have a lot of my own scripts that use gbuild and all need to be updated (including calls to prodloc), but I don't know how to do that yet. So far it doesn't matter whether I work with the ec or the nc target.
Maybe it's a good idea to just change the target script so that you can optionally pass it a path to the target and you make your own scripts that call the target script with the path you want.

Building the targets (ec/nc,) can be automated and you can pass your own paths there.
See here (my files from Syhra): https://e.pcloud.link/publink/show?code=kZ2YDxZiJTtUwmximjCSSXIb2xu6ky0ebUk#folder=13863404460&tpl=publicfolderlist
e.g.
echo +++++ Build EC-NT target
call %scriptpath%\buildbbx <%datpath%\createEC.dat >logec.dat

OK, there's now a lot of benefit, but I don't think you should unnecessarily complicate an already quite complex system.

Agree - perhaps we should leave this as-is if people are relying on the current names in their automation. I have become used to the SDK-style layout of having an EC and NC target in parallel with minimal effort for switching, but I guess this does not have to be the same for everyone.

I'll think about this some more. The fixes to the pcsn script can probably remain in any case because I have always missed this...

I like the idea to have an easy way to have nc and ec target in parallel, as the change here proposes. The key change in the tool contract is that now target uses gbuild.ec instead of gbuild if -n is not given. The buildbbx is usually usedw ith a full path as in put in automation/script, so the change doesn't matter.

I could imagine to also introduce a environment variable that is, when set, used to input the path to the target. TARGET_DIR for instance. This then will guide buildbbx for its defaults (instead of LOCAL_ROOT+gbuild) and target where the target is that need to be started. This gives no answer (and is independent) of the question how to separate nc and ec variants.

One way of finding the EC and NC variant may be the files

Local/.bbxxip/.bbxxip.nt.nec

that remember the last locations where buildbbx put the EC or NC targets.

Perhaps Local/.bbxxip/.bbxxip.nt could store the target that was most recently built (it doesn't at the moment), and target and pcsn would pick up the location from there. Switching targets would usually be done by calling buildbbx.

This way, target would always refer to the last target that was built/updated, and pcsn would pick up the "right" variant (EC/NC) (instead of using -n to select the NC target). This would work regardless of whether the developer puts both in gbuild (as is the current default), or in gbuild.nc and gbuild.ec (as I like to do).