‘stroke-align’ property issues: why not adapt graphic apps behavior?

[herrstrietzel]

Dear working group,
I came across some Issues/annotations about the stroke-alignment or stroke-align property descibed in the spec/draft documentations (sorry I'm not sure if I got the latest revisions).

Frankly, I wonder why SVG shouldn't adopt the "defacto standard" behaviour of graphics applications like Adobe Illustrator - as it was established ~ in the late 90s. (Actually, most other applications also use the same logic to handle stroke alignments).

This is an highly anticipated feature and a behavior deviating from the common graphic application concepts would both:

• confuse most devs/designers also using these applications for complex SVG creation (maybe also switching between coding and graphic editing context)
• complicate application implementation for developers/vendors for a consistent SVG stroke align export and import

I'm referring to these sections:

Issue 5: How does this apply to open path segments? How are end caps handled?

Just ignore stroke-alignment completely, since there is no "inner" side of an open path. In the aforementioned apps you won't be able to change the alignment setting

How are dashes handled? Are they based on original path?

The same should apply to stroked dashes if they are open - ignore stroke alignment

How does this apply to paths with loops? Is the region inside the red circle in the below figure part of the stroked (as shown)? Are internal edges stroked if the fill rule is 'nonzero'; if so how? (Shown without stroking below.)

The exspected result would be similar to a masked stroke with fill-rule even-odd applied

So all in all:
center(default)

inner

outer

The above screenshots come from my testbed on codepen with a polyfill-like helper. They replicate quite accurately the expected behavior from Adobe Illustrator, Affinity Designer, Figma etc.
Sorry, if I missed something.

2.2. Specifying stroke alignment: the ‘stroke-alignment’ property