APT NC PART PROGRAMMING

No.

It could be, as the interpreter is a pluggable component. You can configure the interpreter to be used in the INI file.

There is an example config which uses a non-g-code interpreter:
github.com/LinuxCNC/linuxcnc/blob/master...sim/axis/canterp.ini

This line:
INTERPRETER = libcanterp.so

means that it uses input files that look like this:

github.com/LinuxCNC/linuxcnc/blob/master.../canterp_example.can

So: No, linuxcnc only currently supports G-code and the (example) .can as input files. But if someone wrote an interpreter, it could use any other input file type.

I think that going through G-code might be inefficient, though.

The LinuxCNC G-code interpreter converts G-code to canonical commands:

github.com/LinuxCNC/linuxcnc/blob/master...l_intf/canon.hh#L199

And the vast majority of what is produced is a sting of straight-traverse, arc_feed and straight_feed commands.

Modifying the APT processor to go straight to these rather than via G-code might be a more satisfactory solution.

Who are you asking, and which format?

It doesn't really exist as a file. It is the stuff that gets sent from the interpreter to the motion system in LinuxCNC.

For example, here is what happens when LinuxCNC interprets a G1 command:

github.com/LinuxCNC/linuxcnc/blob/master...erp_convert.cc#L4522

As a demonstration of pluggable interpreters there is a demonstration interpreter called "canterp" that converts files like this to canonical actions: github.com/LinuxCNC/linuxcnc/blob/master.../canterp_example.can
But that shouldn't be created by an APT interpreter, there should not be an intermediate format.

But: Is there really a requirement for this? It is probably a lot of work. Who would use it?

A similar effort might create a STEP-NC interpreter, which might be more useful (or not)