JET_Affinity

Regardless, the request for a hairline stroke weight setting is valid. (It's been brought up before in other threads.)
For those not familiar, a hairline stroke weight always renders at the smallest width possible on the output device, be it your monitor or an imagesetter. This is advantageous when drawing paths in detailed illustrations, during which we are constantly zooming in and out. Having stroke weight set to hairline feels more precise and is less distracting because the stroke weight is always drawn the same, regardless of zoom. The extreme zooming capabilities of Affinity as compared to other programs buttresses the point.
It's a great feature, a standard setting in PostScript, and it should be provided in every vector drawing software.
JET

Something I hope all would consider: The intents (and therefore requirements) of distorting type, as opposed to general artwork.
I grew up working in sign shops, long before the advent of digital type. (I'm proud to say I can still twirl a lettering quill.)
The trouble with automated pre-set envelope distortions as usually implemented is that they treat type the same way they treat any other vector paths, when usually it shouldn't be.
I'm not talking about deliberate effects like the water-drop examples. I'm talking about the ubiquitous things like curving what is supposed to read like normal text around circular emblems, the ess-curved "flag" baselines, the 'hero' headlines, and especially the whole plethora of attempts to emulate retro signage styles. The result, more often than not, is really amateurish adulterations of good type.
All those classic treatments of type are why software since the earliest days, long before vector envelope effects in every drawing program, have been separate features implemented as options for live type-on-path objects, especially the one called various names like "Vertical" or "Skew."
The good thing about that very important treatment is that these things are maintained, as they should be:
The proper "uprightness" of the glyphs The straightness of their vertical strokes The proportion of horizontal strokes to verticals The only bad thing is that the straight horizontals of the glyphs skew, but remain straight.
Typical general-purpose envelope distortion features know nothing of this.
That's why I'd like to see an envelope distortion that knows when it's dealing with type, not just random vector paths. Implementing it as a separate type-specific envelope feature wouldn't hurt my feelings a bit.
JET

As in many features, the devil is in the details. And again: just because Illustrator dominates the market segment does not necessarily mean it is the program to emulate. Typically, Illustrator new features seem to be designed more for an initial "wow factor" when introduced, than thoroughly thought-out. Its first introduction of a warp tool was a case-in-point, which then cascaded down to other subsequently introduced distortion features. Those devilish details can make all the difference between just another "me, too" copycat feature and an elegantly more powerful implementation.
When Illustrator finally got around to having an enveloping tool, its primary historic rival, FreeHand already had one. There was a subtle difference: In FreeHand, the user had control over whether or not the envelope, when initially applied, already had its node curve handles extended.
This "tiny" interface detail made all the difference.
I dare say the simplest, most basic, and therefore most common use for a warp effect is to simply distort the rectangular envelope of a selection by independently moving its corners so as to make the content artwork fit a surface in the illustration that is viewed at an angle; like simply putting a graphic onto the side of a drawn box or monitor screen that isn't viewed "straight on."
That was a simple, straightforward, few clicks in FreeHand. It was a tedious nightmare in Illustrator. Why? For one simple reason: Illustrator's envelope insisted upon being created with its nodes' curve handles already pre-extended by the rule-of-thumb 1/3 length of the segments. In FreeHand, the user was provided control over that.
That was commensurate with a preceding interface superiority in FreeHand: Its provision of auto-retract and auto-extend options which did not appear in Illustrator until much later and which, as usual, still fall short of FreeHand's implementation due to other pre-established "underlying foundations" of the interface. Specifically, it was related to the fact that FreeHand "knew the difference" between paths' being selected at the object level as opposed to merely having all of its individual nodes selected. That engrained foundational inferiority plagues Illustrator to this day, being directly related to Illustrator's now almost universally mimicked interface convention of having two separate primary selection tools.
So thanks, Mithferion, for starting a forward-looking feature discussion thread, as opposed to the pandemic "I want this feature [ just like the only program I've ever used has] and I want it now!" demands. We need more of this. It's what could lead to more powerful innovation instead of just more same-old, same-old mediocrity (like—I hate to say—the frankly disappointing arrowheads feature).
JET

Amazing that an ex-user still have so much time to whine about the software you don't want to use. Of course there are things Affinity does not do as well as some would like. But no one is forcing you to use it and no app is for everyone. I miss some things in Affinity too, but for me as a whole it has giving me a lot and I like to use the apps, despite some shortcomings. If you want more advanced vector support but not illustrator, just try Vectorstyler. This is an app with great potential, and many of the features Affinity users request. Despite that the UX is still better with Affinity so its only a side gig.

Regardless, the request for a hairline stroke weight setting is valid. (It's been brought up before in other threads.)
For those not familiar, a hairline stroke weight always renders at the smallest width possible on the output device, be it your monitor or an imagesetter. This is advantageous when drawing paths in detailed illustrations, during which we are constantly zooming in and out. Having stroke weight set to hairline feels more precise and is less distracting because the stroke weight is always drawn the same, regardless of zoom. The extreme zooming capabilities of Affinity as compared to other programs buttresses the point.
It's a great feature, a standard setting in PostScript, and it should be provided in every vector drawing software.
JET

Again, a topic conjures up fond memories of FreeHand.
FreeHand had just one kind of text object. It could be set to auto-expand horizontally (i.e., becoming functionally equivalent to a so-called "art text" object in other programs) by simply doubleClicking the right middle handle. It could be set to auto-fit its contained text vertically by doubleClicking its bottom middle handle. The text objects could be bound to and released from paths (instead of being treated as a separate "path text" object). They could be threaded, whether bound to a path or not. They could be set to auto-expand when bound to a path, thereby preventing the problem of accidentally truncated text in complex maps, as is so chronically common in maps built in Illustrator.
This is conceptually parallel to the fact that FreeHand also never had any need for two separate selection tools. Its single selection tool enabled you to edit paths at the whole object level and at the node editing level. That elegant interface design made path drawing far less tedious, more fluidly efficient, and more powerful than any drawing program that insists on following Adobe's hideous model of two primary selection tools.
Macromedia finally gave in to ill-advised "demand" from Illustrator users to add a second pointer tool. When added, it provided absolutely no additional functionality. It was literally nothing but an accommodation to Illustrator-habituated users who just refused to learn that it was absolutely unnecessary. FreeHand users simply ignored it. It was not until FreeHand's very last version that its white pointer did anything that the black pointer didn't, and even that was a minor detail that could have been implemented without adding another tool.
Despite Illustrator's two selection tools (three, really, when you include the ill-conceived "Convert AnchorPoint Tool")--actually because of it--Illustrator to this day does not "know the difference" between a path being selected at the object level versus merely having all its AnchorPoints selected. This causes all kinds of silly inconsistencies such as being unable to use the Break Anchor Point command when all of a path's Anchor Points are selected. (You have to unintuitively de-select at least one Anchor Point for it to work.)
Because object selection is so bedrock foundational to an object-based program, its tedious effects "cascade upward" throughout the program's interface. In a nutshell, it's what makes working in Illustrator feel as frustrating to beginners as trying to eat spaghetti with a single chopstick.
It's because Illustrator's white pointer behavior is conceptually "upside down" from intuition. It's the selection tool you have to use to edit a path.  But its first click always selects the most "internal" sub-part element of whatever construct you are trying to manipulate. Rather than intuitively selecting an object of interest and then "digging down" to its subparts with subsequent clicks, Illustrator's scheme first selects some "molecule" of the object of interest and requires use of a modifier key and subsequent clicks to "back out" of it to each next higher level.
It's metaphorically like getting up in the morning and needing a pair of socks. So you intuitively try to open your sock drawer. But your hand passed right through the closed drawer, and the only thing you can grab is a single thread of a single sock. So you have to then use both your hands to select a single sock, and grab again with both hands to grasp the folded up pair. All this "Bizzarro World" behavior instead of simply opening the drawer and grabbing the pair of socks.
The beginning of the end of FreeHand was not the Adobe acquisition. It was when it started to emulate Illustrator's hideous interface.
Unfortunately, because things like selection tools and text objects are foundational to the program built upon them, I'm sure it's too late to back-track the existing conventional-wisdom (i.e. "like Illustrator") in either case. But I say again: If you want to build a better drawing program, Adobe Illustrator is not the program to emulate.
JET

But why only the midpoint of a segment? What if I want to snap to thirds of a segment? Or divide a segment into fifths.
An Add Nodes Per Segment command would enable one to create snap candidates at any fractional increment along a segment.
JET

Nonsense. Since when is merely specifying a line by length and angle or drawing to user-defined scale only for 'CAD tools'? Egads, man, by that kind of logic, no 'CAD tool' should be able to colorize a vector object, either. Do you know why it's called a Bezier curve, and what industry Mr. Bezier was working in?
Mainstream vector drawing programs are very general-purpose. They are not just used for loosey-goosey freehand scribbling in an ill-conceived attempt to emulate 'natural media' on a tiny cell phone screen with a pudgy finger. These programs are routinely used for:
Cleaning up and augmenting CAD exports to make them suitable for commercial-quality reproduction Drawing die cuts for commercial collateral and package design Drawing garden plats Maps of all kinds Typeface design Bird's-eye views of theme parks for visitor's brochures Conceptuals and working drawings for commercial signage, storefronts, interior designs, point-of-sale displays, billboards Cutting paths for sign vinyl plotters and routers Architectural concepts Trade show displays and booth sites, both as conceptual renderings and as final working drawings All manner of info graphics And, yes, axonometric drawing (assembly diagrams for everything from colorful pre-school toys to mundane light fixtures) …I could go on indefinitely. Since the mid-80s I've been using FreeHand, Canvas, Draw, Illustrator, Flash, and most others that have come along in this software category since then to do these kinds of things, all of which are squarely within the real world domain of profitable commercial illustration.
JET
 

Regardless, the request for a hairline stroke weight setting is valid. (It's been brought up before in other threads.)
For those not familiar, a hairline stroke weight always renders at the smallest width possible on the output device, be it your monitor or an imagesetter. This is advantageous when drawing paths in detailed illustrations, during which we are constantly zooming in and out. Having stroke weight set to hairline feels more precise and is less distracting because the stroke weight is always drawn the same, regardless of zoom. The extreme zooming capabilities of Affinity as compared to other programs buttresses the point.
It's a great feature, a standard setting in PostScript, and it should be provided in every vector drawing software.
JET

It's also another "low hanging fruit" opportunity to surpass Illustrator. Throughout the FreeHand vs Illustrator competitive years, FreeHand users knew what a huge advantage it was to work with hairline strokes in the normal full-color interface. The only way to get hairline editing behavior in Illustrator is to put it in its lame Outline Mode.
JET

I’m not an admin but I dare to say what they would say: It’s done when it’s done.
What’s the point of asking when it’s done? Just continue to use Illustrator or whatever until you get the notice that it’s here. It’s not going to come any quicker by constantly asking.

Regardless, the request for a hairline stroke weight setting is valid. (It's been brought up before in other threads.)
For those not familiar, a hairline stroke weight always renders at the smallest width possible on the output device, be it your monitor or an imagesetter. This is advantageous when drawing paths in detailed illustrations, during which we are constantly zooming in and out. Having stroke weight set to hairline feels more precise and is less distracting because the stroke weight is always drawn the same, regardless of zoom. The extreme zooming capabilities of Affinity as compared to other programs buttresses the point.
It's a great feature, a standard setting in PostScript, and it should be provided in every vector drawing software.
JET

Even without a set of dimensioning tools, length and area of a selected path should be provided in the interface of any serious drawing program.
 
JET

For those not familiar:
Illustrator's awkwardly named Merge performs two basic Boolean operations in one move, based on their color:
It Unions touching (abutting or overlapping) fills of the same color. It Punches (subtracts) overlapping fills of different colors. (Frontmost punches others). So it results in the minimal individual paths around visually contiguous regions of the same color.
One common real-world use case for this is when preparing a design for cutting from sign vinyl. In that common workflow, you don't want any cuts across same-colored regions, because as the vinyl shrinks over time, void slivers appear. So the Merge command saves a lot of time and tedium.
However, it addresses just half of that use case: When different colors of a sign vinyl design need to appear to abut, one actually does need a small amount of overlap for the very same reason: It's very difficult to physically perfectly abut different-colored pieces of vinyl when applying it, and even if you could, the eventual shrinkage would again cause slivers between them.
The practical fix is analogous to that of color trapping (chokes, spreads, and overprinting) in print.
So this is yet another opportunity to improve upon an Illustrator feature by addressing its shortcomings instead of just mimicking it in 'me, too' fashion: Such a command should incorporate an Overlap setting that would default to zero, but could be set by the user whenever a trap (parallel to the shapes) is needed. That would address the tedium of having to manually apply Offset Path (in AI) or Contour (in Affinity) to the results of a Merge operation. In other words, the suggested new feature function should incorporate three basic operations (union, subtract, and offset), not just two (union and subtract).
Illustrator could have long since addressed this by providing a checkbox in its Merge command: Respect Manual Traps or Respect Overprinting Strokes. But it doesn't. And its 'Pathfinders' generally ignore strokes anyway. Expand Appearance 'sees' manual traps built in Illustrator, but treats them as 'third' colors instead of as the same color as the spread or choked color.
Another low-hanging-fruit opportunity to surpass Illustrator's functionality by avoiding its endemic characteristic of too many grab-bag standalone features being 'unaware' of each other.
JET

Macro, unlikely. Too many variables. Although Windows applications tend to refer to Visual Basic scripts as 'macros', generally speaking, a macro is just a recording of a sequence of individual performed operations or commands provided in the standard interface, like so-called Actions in Adobe apps. The sequence would likely be different for every piece of artwork, thereby negating the advantage.
Scripting, on the other hand, maybe. But that's far more ambitious. A good scripting implementation provides for variables and conditional logic. But the operative phrase here is "good implementation". I've resorted to writing Javascript to create a substantial collection of 'missing features' in Illustrator, and yes, I am one of those who dearly wants to see Affinity provide a complete and well-documented Javascript object model as soon as its feature set is more fully fleshed-out and stabilized. But even so, it was the continual frustration of scripting AI that I had to resort to it for no-brainer missing functionality like, for just one example, a simple reverse path command. (And no, no one need trot out clicking an endNode with the Pen Tool.)
But  it comes immediately to mind in this context that Illustrator's Javascript (as of CS6, after which I abandoned it because I will not enslave myself nor have my business-critical files held hostage to a software vendor) provides no method for collision detection between paths (something I asked for throughout the years of writing AI scripting). So one might be able to devise into the script a repetitive loop of 'tests' to determine which paths actually overlap. But I'd be gritting my teeth doing that just because the functionality should be in the standard interface.
The use case I described (vinyl cutting) is one in which something akin to Illustrator's Merge command quickly becomes indispensable. But its utility is certainly not limited to that. It's one of the kind of features that a user may not immediately recognize the 'need' for, but will quite likely find many uses for once it is provided. Adding a button and a slider to a Boolean palette would not constitute excessive gratuitous tool-glut.
If one thinks it through, it becomes evident that the so-called Merge Pathfinder is doing essentially much the same thing that the much later so-called Live Paint and Shape Builder features are doing. They're just doing it as a 'live effect' with an elaborate tool interface, instead of by a simple command. Much of Illustrator's tool glut boils down to 're-packaging' of existing functionality with more elaborate interfaces.
Of course it did. And I dare say, like many other things, it probably appeared before Illustrator's trapping functions. But FreeHand did not have a command akin to the one specified in this thread. The Merge command was one of the precious few positives in having to segue to AI after Adobe bought and killed FreeHand.
I'd have to fire up the old bulbous pinstripe Mac G4 relic to verify, but something in my own vague recollection suggests that FreeHand's Boolean path operations could be made to incorporate manually-built traps.
All this is why I continually argue that we need to think beyond Illustrator. Illustrator is just one of the old 'Big Four" (FreeHand, Illustrator, CorelDRAW, Canvas). A lot of redundant clutter lingers from the ad-hoc development since those days and elegance is lost when new offerings just 'copy what [historically] sells.' Elegance is achieved by providing fully thought-through and integrated functional power just beneath a clean, minimalist, but intuitive interface. The clutter of the older apps is nowadays nothing to emulate.
My favorite example of the 'everybody now does it, so it must be right' fallacy is the now omnipresent confused, always-shifting, schizophrenic  'Bar' that can't decided whether it's a Tools Option Bar or a Commands Bar. Every graphics software developer should be required to understand and experience the advantage of FreeHand's incomparable Inspector Palette. (Closest thing to it in any program I use is in the Layout Mode of FileMaker Pro; a database program, of all things.)
JET

For those not familiar:
Illustrator's awkwardly named Merge performs two basic Boolean operations in one move, based on their color:
It Unions touching (abutting or overlapping) fills of the same color. It Punches (subtracts) overlapping fills of different colors. (Frontmost punches others). So it results in the minimal individual paths around visually contiguous regions of the same color.
One common real-world use case for this is when preparing a design for cutting from sign vinyl. In that common workflow, you don't want any cuts across same-colored regions, because as the vinyl shrinks over time, void slivers appear. So the Merge command saves a lot of time and tedium.
However, it addresses just half of that use case: When different colors of a sign vinyl design need to appear to abut, one actually does need a small amount of overlap for the very same reason: It's very difficult to physically perfectly abut different-colored pieces of vinyl when applying it, and even if you could, the eventual shrinkage would again cause slivers between them.
The practical fix is analogous to that of color trapping (chokes, spreads, and overprinting) in print.
So this is yet another opportunity to improve upon an Illustrator feature by addressing its shortcomings instead of just mimicking it in 'me, too' fashion: Such a command should incorporate an Overlap setting that would default to zero, but could be set by the user whenever a trap (parallel to the shapes) is needed. That would address the tedium of having to manually apply Offset Path (in AI) or Contour (in Affinity) to the results of a Merge operation. In other words, the suggested new feature function should incorporate three basic operations (union, subtract, and offset), not just two (union and subtract).
Illustrator could have long since addressed this by providing a checkbox in its Merge command: Respect Manual Traps or Respect Overprinting Strokes. But it doesn't. And its 'Pathfinders' generally ignore strokes anyway. Expand Appearance 'sees' manual traps built in Illustrator, but treats them as 'third' colors instead of as the same color as the spread or choked color.
Another low-hanging-fruit opportunity to surpass Illustrator's functionality by avoiding its endemic characteristic of too many grab-bag standalone features being 'unaware' of each other.
JET

For those not familiar:
Illustrator's awkwardly named Merge performs two basic Boolean operations in one move, based on their color:
It Unions touching (abutting or overlapping) fills of the same color. It Punches (subtracts) overlapping fills of different colors. (Frontmost punches others). So it results in the minimal individual paths around visually contiguous regions of the same color.
One common real-world use case for this is when preparing a design for cutting from sign vinyl. In that common workflow, you don't want any cuts across same-colored regions, because as the vinyl shrinks over time, void slivers appear. So the Merge command saves a lot of time and tedium.
However, it addresses just half of that use case: When different colors of a sign vinyl design need to appear to abut, one actually does need a small amount of overlap for the very same reason: It's very difficult to physically perfectly abut different-colored pieces of vinyl when applying it, and even if you could, the eventual shrinkage would again cause slivers between them.
The practical fix is analogous to that of color trapping (chokes, spreads, and overprinting) in print.
So this is yet another opportunity to improve upon an Illustrator feature by addressing its shortcomings instead of just mimicking it in 'me, too' fashion: Such a command should incorporate an Overlap setting that would default to zero, but could be set by the user whenever a trap (parallel to the shapes) is needed. That would address the tedium of having to manually apply Offset Path (in AI) or Contour (in Affinity) to the results of a Merge operation. In other words, the suggested new feature function should incorporate three basic operations (union, subtract, and offset), not just two (union and subtract).
Illustrator could have long since addressed this by providing a checkbox in its Merge command: Respect Manual Traps or Respect Overprinting Strokes. But it doesn't. And its 'Pathfinders' generally ignore strokes anyway. Expand Appearance 'sees' manual traps built in Illustrator, but treats them as 'third' colors instead of as the same color as the spread or choked color.
Another low-hanging-fruit opportunity to surpass Illustrator's functionality by avoiding its endemic characteristic of too many grab-bag standalone features being 'unaware' of each other.
JET

For those not familiar:
Illustrator's awkwardly named Merge performs two basic Boolean operations in one move, based on their color:
It Unions touching (abutting or overlapping) fills of the same color. It Punches (subtracts) overlapping fills of different colors. (Frontmost punches others). So it results in the minimal individual paths around visually contiguous regions of the same color.
One common real-world use case for this is when preparing a design for cutting from sign vinyl. In that common workflow, you don't want any cuts across same-colored regions, because as the vinyl shrinks over time, void slivers appear. So the Merge command saves a lot of time and tedium.
However, it addresses just half of that use case: When different colors of a sign vinyl design need to appear to abut, one actually does need a small amount of overlap for the very same reason: It's very difficult to physically perfectly abut different-colored pieces of vinyl when applying it, and even if you could, the eventual shrinkage would again cause slivers between them.
The practical fix is analogous to that of color trapping (chokes, spreads, and overprinting) in print.
So this is yet another opportunity to improve upon an Illustrator feature by addressing its shortcomings instead of just mimicking it in 'me, too' fashion: Such a command should incorporate an Overlap setting that would default to zero, but could be set by the user whenever a trap (parallel to the shapes) is needed. That would address the tedium of having to manually apply Offset Path (in AI) or Contour (in Affinity) to the results of a Merge operation. In other words, the suggested new feature function should incorporate three basic operations (union, subtract, and offset), not just two (union and subtract).
Illustrator could have long since addressed this by providing a checkbox in its Merge command: Respect Manual Traps or Respect Overprinting Strokes. But it doesn't. And its 'Pathfinders' generally ignore strokes anyway. Expand Appearance 'sees' manual traps built in Illustrator, but treats them as 'third' colors instead of as the same color as the spread or choked color.
Another low-hanging-fruit opportunity to surpass Illustrator's functionality by avoiding its endemic characteristic of too many grab-bag standalone features being 'unaware' of each other.
JET

For those not familiar:
Illustrator's awkwardly named Merge performs two basic Boolean operations in one move, based on their color:
It Unions touching (abutting or overlapping) fills of the same color. It Punches (subtracts) overlapping fills of different colors. (Frontmost punches others). So it results in the minimal individual paths around visually contiguous regions of the same color.
One common real-world use case for this is when preparing a design for cutting from sign vinyl. In that common workflow, you don't want any cuts across same-colored regions, because as the vinyl shrinks over time, void slivers appear. So the Merge command saves a lot of time and tedium.
However, it addresses just half of that use case: When different colors of a sign vinyl design need to appear to abut, one actually does need a small amount of overlap for the very same reason: It's very difficult to physically perfectly abut different-colored pieces of vinyl when applying it, and even if you could, the eventual shrinkage would again cause slivers between them.
The practical fix is analogous to that of color trapping (chokes, spreads, and overprinting) in print.
So this is yet another opportunity to improve upon an Illustrator feature by addressing its shortcomings instead of just mimicking it in 'me, too' fashion: Such a command should incorporate an Overlap setting that would default to zero, but could be set by the user whenever a trap (parallel to the shapes) is needed. That would address the tedium of having to manually apply Offset Path (in AI) or Contour (in Affinity) to the results of a Merge operation. In other words, the suggested new feature function should incorporate three basic operations (union, subtract, and offset), not just two (union and subtract).
Illustrator could have long since addressed this by providing a checkbox in its Merge command: Respect Manual Traps or Respect Overprinting Strokes. But it doesn't. And its 'Pathfinders' generally ignore strokes anyway. Expand Appearance 'sees' manual traps built in Illustrator, but treats them as 'third' colors instead of as the same color as the spread or choked color.
Another low-hanging-fruit opportunity to surpass Illustrator's functionality by avoiding its endemic characteristic of too many grab-bag standalone features being 'unaware' of each other.
JET

For those not familiar:
Illustrator's awkwardly named Merge performs two basic Boolean operations in one move, based on their color:
It Unions touching (abutting or overlapping) fills of the same color. It Punches (subtracts) overlapping fills of different colors. (Frontmost punches others). So it results in the minimal individual paths around visually contiguous regions of the same color.
One common real-world use case for this is when preparing a design for cutting from sign vinyl. In that common workflow, you don't want any cuts across same-colored regions, because as the vinyl shrinks over time, void slivers appear. So the Merge command saves a lot of time and tedium.
However, it addresses just half of that use case: When different colors of a sign vinyl design need to appear to abut, one actually does need a small amount of overlap for the very same reason: It's very difficult to physically perfectly abut different-colored pieces of vinyl when applying it, and even if you could, the eventual shrinkage would again cause slivers between them.
The practical fix is analogous to that of color trapping (chokes, spreads, and overprinting) in print.
So this is yet another opportunity to improve upon an Illustrator feature by addressing its shortcomings instead of just mimicking it in 'me, too' fashion: Such a command should incorporate an Overlap setting that would default to zero, but could be set by the user whenever a trap (parallel to the shapes) is needed. That would address the tedium of having to manually apply Offset Path (in AI) or Contour (in Affinity) to the results of a Merge operation. In other words, the suggested new feature function should incorporate three basic operations (union, subtract, and offset), not just two (union and subtract).
Illustrator could have long since addressed this by providing a checkbox in its Merge command: Respect Manual Traps or Respect Overprinting Strokes. But it doesn't. And its 'Pathfinders' generally ignore strokes anyway. Expand Appearance 'sees' manual traps built in Illustrator, but treats them as 'third' colors instead of as the same color as the spread or choked color.
Another low-hanging-fruit opportunity to surpass Illustrator's functionality by avoiding its endemic characteristic of too many grab-bag standalone features being 'unaware' of each other.
JET

For those not familiar:
Illustrator's awkwardly named Merge performs two basic Boolean operations in one move, based on their color:
It Unions touching (abutting or overlapping) fills of the same color. It Punches (subtracts) overlapping fills of different colors. (Frontmost punches others). So it results in the minimal individual paths around visually contiguous regions of the same color.
One common real-world use case for this is when preparing a design for cutting from sign vinyl. In that common workflow, you don't want any cuts across same-colored regions, because as the vinyl shrinks over time, void slivers appear. So the Merge command saves a lot of time and tedium.
However, it addresses just half of that use case: When different colors of a sign vinyl design need to appear to abut, one actually does need a small amount of overlap for the very same reason: It's very difficult to physically perfectly abut different-colored pieces of vinyl when applying it, and even if you could, the eventual shrinkage would again cause slivers between them.
The practical fix is analogous to that of color trapping (chokes, spreads, and overprinting) in print.
So this is yet another opportunity to improve upon an Illustrator feature by addressing its shortcomings instead of just mimicking it in 'me, too' fashion: Such a command should incorporate an Overlap setting that would default to zero, but could be set by the user whenever a trap (parallel to the shapes) is needed. That would address the tedium of having to manually apply Offset Path (in AI) or Contour (in Affinity) to the results of a Merge operation. In other words, the suggested new feature function should incorporate three basic operations (union, subtract, and offset), not just two (union and subtract).
Illustrator could have long since addressed this by providing a checkbox in its Merge command: Respect Manual Traps or Respect Overprinting Strokes. But it doesn't. And its 'Pathfinders' generally ignore strokes anyway. Expand Appearance 'sees' manual traps built in Illustrator, but treats them as 'third' colors instead of as the same color as the spread or choked color.
Another low-hanging-fruit opportunity to surpass Illustrator's functionality by avoiding its endemic characteristic of too many grab-bag standalone features being 'unaware' of each other.
JET

For clarity, I certainly hope no one is asking for this to be a default behavior.
I do not want an endNode of a path to auto-join to another path just because I drag it to within pick distance of another path's end. There are countless situations in illustration in which one draws coincident paths that should not be joined. Look no further than paths of different weights, color, or other style attributes that nonetheless need to have coincident ends. What about when more than two endNodes are coincident? How is the program supposed to know which path I would want it to auto-join to?
The auto-joining behavior of Adobe Illustrator's Pen, for example, is one of its most infuriatingly intrusive stumbling blocks. To avoid its infernal insistence on auto-joining to other deselected paths when drawing, you actually have to invoke this ridiculous override:
Mousedown somewhere that you don't want the next node to be Press and hold the spacebar Drag to where you do want it the node to be Mouseup Release the spacebar A path drawing tool is not a selection tool, and should not act like one. It has no business affecting unselected paths just because you need to place a node within pick distance of another path's endnode. Nor should it occur when just dragging an endNode.
At most, any such behavior should have to be invoked by a keyboard shortcut. It should not be default behavior.
The  task of cleaning up DXF files is an oft-cited use case, and one with which I am quite familiar, having been doing technical illustration since well before personal computers. But it's still a specifically vertical use case; nothing that should be cited to justify a default behavior. Other programs accommodate it with separate, explicitly-invoked menu commands. You select the paths you want to be affected and then invoke the joining command (with whatever parameters offered in a dialog). If that's what you're recommending, I'm fine with it. But auto-joining as default behavior is bad.
JET

For clarity, I certainly hope no one is asking for this to be a default behavior.
I do not want an endNode of a path to auto-join to another path just because I drag it to within pick distance of another path's end. There are countless situations in illustration in which one draws coincident paths that should not be joined. Look no further than paths of different weights, color, or other style attributes that nonetheless need to have coincident ends. What about when more than two endNodes are coincident? How is the program supposed to know which path I would want it to auto-join to?
The auto-joining behavior of Adobe Illustrator's Pen, for example, is one of its most infuriatingly intrusive stumbling blocks. To avoid its infernal insistence on auto-joining to other deselected paths when drawing, you actually have to invoke this ridiculous override:
Mousedown somewhere that you don't want the next node to be Press and hold the spacebar Drag to where you do want it the node to be Mouseup Release the spacebar A path drawing tool is not a selection tool, and should not act like one. It has no business affecting unselected paths just because you need to place a node within pick distance of another path's endnode. Nor should it occur when just dragging an endNode.
At most, any such behavior should have to be invoked by a keyboard shortcut. It should not be default behavior.
The  task of cleaning up DXF files is an oft-cited use case, and one with which I am quite familiar, having been doing technical illustration since well before personal computers. But it's still a specifically vertical use case; nothing that should be cited to justify a default behavior. Other programs accommodate it with separate, explicitly-invoked menu commands. You select the paths you want to be affected and then invoke the joining command (with whatever parameters offered in a dialog). If that's what you're recommending, I'm fine with it. But auto-joining as default behavior is bad.
JET

For clarity, I certainly hope no one is asking for this to be a default behavior.
I do not want an endNode of a path to auto-join to another path just because I drag it to within pick distance of another path's end. There are countless situations in illustration in which one draws coincident paths that should not be joined. Look no further than paths of different weights, color, or other style attributes that nonetheless need to have coincident ends. What about when more than two endNodes are coincident? How is the program supposed to know which path I would want it to auto-join to?
The auto-joining behavior of Adobe Illustrator's Pen, for example, is one of its most infuriatingly intrusive stumbling blocks. To avoid its infernal insistence on auto-joining to other deselected paths when drawing, you actually have to invoke this ridiculous override:
Mousedown somewhere that you don't want the next node to be Press and hold the spacebar Drag to where you do want it the node to be Mouseup Release the spacebar A path drawing tool is not a selection tool, and should not act like one. It has no business affecting unselected paths just because you need to place a node within pick distance of another path's endnode. Nor should it occur when just dragging an endNode.
At most, any such behavior should have to be invoked by a keyboard shortcut. It should not be default behavior.
The  task of cleaning up DXF files is an oft-cited use case, and one with which I am quite familiar, having been doing technical illustration since well before personal computers. But it's still a specifically vertical use case; nothing that should be cited to justify a default behavior. Other programs accommodate it with separate, explicitly-invoked menu commands. You select the paths you want to be affected and then invoke the joining command (with whatever parameters offered in a dialog). If that's what you're recommending, I'm fine with it. But auto-joining as default behavior is bad.
JET

So I am new to Affinity. 
I was an Adobe user and recently upgraded to the apple 2021 macbook.
I was using the Adobe CS6 suite to do all my design work and photo editing. When I got my new macbook I learned my pre-purchased Adobe CS6 did not support the new m1 chip so was facing the decision to pay a monthly Adobe subscription of $53(USD) per month forever! After 5 years, this would have amounted to $3180 (USD). That just seems so unreasonable to me because I feel I am 'priced out' of trying to design. 
Cue Affinity, the life-savers! 
Now that I've been using Affinity, Adobe couldn't pay me to switch back. Smart and thoughtful design + accessible honest pricing. It's also exciting to work with something new and robust like Affinity.
This is what design is all about.