I disagree, the JS code is immediately understandable without having to lookup anything. You could do it in pure XML but the result would probably be much more verbose.

To be equivalent the SVG `<path>` element would probably need to take an idref to something like a `<draw>` element. This is how I would guess the equivalent would be:

    <draw id="my-path">
      <move-to x="10" y="10" />
      <line-to x="90" y="10" />
      <line-to x="90" y="90" />
      <line-to x="10" y="90" />
      <line-to x="10" y="10" />
    </draw>

    <path draw="my-path" />

EDIT: Come to think of it, the above is probably a lot easier to animate using CSS or SMIL. Animating the `d` attribute on `<path>`s is theoretically possible but in practice weird at best or browser inconsistent or simply impossible at worst.

EDIT 2: In D3 it is not uncommon to draw area graphs with a thick border on top. The only way to do this is with two `<path>`s with almost identical `d` attributes. Allowing drawings to be strung together with multiple idrefs could solve that:

    <draw id=line-path><!-- ... --></draw>
    <draw id="area-box-close">
      <line-to x="100" y="100" />
      <line-to x="0" y="100" />
      <end />
    </draw>
    
    <path draw="line-path" class="line" />
    <path draw="line-path area-box-close" class="area" />

Maybe this isn’t such a bad idea after all.

Yes! That's a lot better IMO, but I suspect that the reason for the custom string with single letter "operators" is because the size overhead was unbearable for SVGs with complex paths (which, being a vector format, should be considered the baseline). The overhead is already pretty massive with the current spec, gzipped you can usually divide the file size by an order of magnitude.

I SVG is pretty inelegant, but it's pragmatical.

I would argue that using something like this would result in a less readable file overall. 85% of people editing SVGs by hand have 0 interest in modifying paths by hand. They likely want to move elements around, change groups, etc. If the d-path was written less compactly, these path definitions, which, again most people don't even care about, would end up taking up the vast majority of the space in the file. It would be impossible to get an idea of the nesting, and super annoying to move things around since they would be huge.

Also: Reminder SVGs goal is presentation, so paths even for a simple monochrome icon have _hundreds_ of control points. Something more intricate or a larger graphic? Thousands easily. All the examples here are toy examples, that don't scale to what SVG is actually used for.