Would you use a feed rate for rotary axes in mm/min (surface speed)?

Problem is if "stupidly slow" was a behavior anyone relied upon, or already based something on, tuxcnc has a point there, there could be subs out there that fixed this issue in gcode, and we might not what to change their behavior with a new default, is just something we have to account for, we have enough users where these seemingly rare occurrences might bite quite a few ppl...
A new INI to force a sensible default, and leaving old configs unchanged seems the right balance.

---

And replying "G93 works for me" is totally fine, this was more of a census to see how many users actually would use the feature, and who already had it covered, one doesn't detract from the other, but give me a rough idea of who looked at it, and who I can ping for testing once it's built

Just thinking about this a bit...

I wonder if a new non-modal gcode could be created that didn't use any INI settings, and simple calculated the appropriate angular feedrate based on the Z0 being at the center of rotation.

In my CAM I have to set A-axis CoR to Z0 for it to work properly, even for simple indexing work.  I wonder if other users are 'used to' programming a rotary axis - at least a 4th axis - with CoR as Z0?

I also wonder if this is going to be more complicated... what if the tool is not just cutting on the rotational axis centerline?  Will the new Gcode/Mcode change (or work with) the trajectory planner to determine the 'real' radius based on rotational axis offset, plus tool diameter?

Sounds like it might get interesting.

Yes, I will try to make the least assumptions as possible, you could be working from Z0 center, or not, you could be working on a lathe or a mill, the spindle could be spinning or the table, you might want the feed to match the tip the side or half way trough the shaft of a tool, I think we need some flexibility, but I'd also compare with what other controllers do, and what a CAM or someone hand writing a gcode would expect...

First of all, GIGO, i.e. processing incorrect data, gives incorrect results.
You can also say that if you ask the wrong question, all the answers will be wrong...
Questions like who would like to do it and whether to do it are the wrong questions, especially when asking a small and non-representative group of a few active users of this forum.

The real question is: HOW NOT TO DO THIS?

And here we know the right answer - NOT like in Mach3.
Mach3 is commercial software, which means that nothing is done to make it work good, but to make the users like it, because the company's income depends on the users' satisfaction.

It works differently in free software - if someone has the time and inclination, they add a new utility, and if someone doesn't like it, they don't use it.
The only problem here is not to break anything and not to let a program with a twenty-year history suddenly start working in a way that is unpredictable for the user.

But let's get back to Mach3.
I don't have the time or inclination to look for better examples, but what I quickly found is completely enough. Here is one of the many screens for changing Mach3 settings:

Notice the "G04 dwell ms" entry in the upper right corner.
The way it works is that depending on whether this item is selected or deselected, the G04 code is interpreted in a different way. There is no need to explain the difference between 3 seconds and 3 milliseconds, and the g-code author may have no idea how his code will be executed.
Let's ignore the sobbing of the operator when his disk goes bad and he has to recreate all the windows and buttons, because that would be offtopic.
The utility we are talking about here is implemented in Mach3. AI writes about it this way: Basically everything is true.
Let's not do the same in LinuxCNC.
The definition of g-code is that it is a description of the tool path and let's stick to it.
The same g-code should be executed in the same way on different machines, and not on each machine differently because the operator changed something in settings...

I will suggest another option... An INI setting that causes any A motion other than a rapid to be an error, in G94 mode, or perhaps a pop-up warning.
A G94.1 mode for "It's G94 but use the X/Y/Z in the INI as the rotary center for calculations" would be nice, but anything "new" is work and learning for operators.
 

tuxcnc, on the Mach3 comparison I think you're aiming at the wrong part. The thing that's bad in Mach3's rotation radius DRO isn't the concept, it's that the radius is a value the operator types per stock and nothing in the program records it. That critique I fully agree with, and it's exactly why a G/M word carrying the radius in the file is the right mechanism, as you said: one file, reusable per diameter in a single program, unused by anyone who doesn't want it. Nothing to argue about there.

Where I disagree is "the same g-code should execute the same way on different machines". That was never true, in LinuxCNC or anywhere else. WRAPPED_ROTARY in the INI already changes what G0 A400 does. The default G64 tolerance, the G20/G21 default, startup codes, and above all the kinematics the machine builder picks, all change how the same file executes. G-code describes a toolpath relative to a machine definition; cross-machine portability has always been the post-processor's job, not the interpreter's. An opt-in INI value that no existing config sets is the same kind of contract as those knobs: unset means behavior identical to today, zero risk to twenty-year-old programs.

And it isn't Mach3 lineage. Siemens has FGREF for exactly this, settable from the program, which is an argument for your G-code form. Fanuc goes further in the direction you dislike: a parameter bit switches rotary feed from deg/min to length/min outright (1404#1 RFD, if I remember the number right). So both ends exist in serious industrial controls.

On "questions like who would like it are the wrong questions": I think asking is precisely the right first step. A project like this stays alive for 20 years because the people building it keep an ear on what users actually need, and because users see that asking can lead somewhere. "Devs build whatever comes to mind, users take it or leave it" is the model that slowly empties a user base. A quick census before sinking weeks into a feature isn't design-by-committee, it's just checking that the work lands with someone. Nobody is bound by the answers; I'll weigh the design on its merits, this thread included.
Net result of the thread so far, the way I read it: G93 covers the CAM crowd, hand-writers would take a G-code word for the radius, and whatever lands must not change behavior on any existing config. That's a useful outcome for a few days of asking.