You probably mean

  (path d M 10 10 H 90 V 90 H 10 L 10 10)

Shore up some nesting for the commands with pattern matching, returning a path struct:

  This is the TXR Lisp interactive listener of TXR 251.
  Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet.
  Garbage collection is on Tuesdays: bring unwanted pointers to curb by 7:30.
  1> (defstruct path () name args)
  #<struct-type path>
  2> (defun parse-path-args (args)
       (match-case args
         ((M @x @y . @rest) ^((M ,x ,y) ,*(parse-path-args rest)))
         ((L @x @y . @rest) ^((L ,x ,y) ,*(parse-path-args rest)))
         ((H @x . @rest) ^((H ,x) ,*(parse-path-args rest)))
         ((V @x . @rest) ^((V ,x) ,*(parse-path-args rest)))
         (())
         (@else (error "bad path arguments: ~s" else))))
  parse-path-args
  3> (defun-match parse-path
       (((path @(symbolp @name) . @args))
        (new path name name args (parse-path-args args)))
       ((@else) (error "bad path syntax: ~s" else)))
  parse-path
  4> (parse-path '(path d M 10 10 H 90 V 90 H 10 L 10 10))
  #S(path name d args ((M 10 10) (H 90) (V 90) (H 10) (L 10 10)))

Error cases:

  5> (parse-path '(path d M 10 10 H 90 V 90 X 10 L 10 10))
  ** bad path arguments: (X 10 L 10 10)
  ** during evaluation of form (error "bad path arguments: ~s"
                                    else)
  ** ... an expansion of (progn (error "bad path arguments: ~s"
                                     else))
  ** which is located at expr-2:2
  ** run with --backtrace to enable backtraces
  6> (parse-path '(paath d M 10 10 H 90 V 90 X 10 L 10 10))
  ** bad path syntax: paath d M 10 10 H 90 V 90 X 10 L 10 10
  ** during evaluation of form (error `bad path syntax: @else`)
  ** ... an expansion of (progn (error `bad path syntax: @else`))
  ** which is located at expr-3:1
  ** run with --backtrace to enable backtraces

I think that’s too flat. There’s no easy place to put the width and suchlike. I think you’d want something like:

  (path (M 10 10 H 90 V 90 H 10 L 10 10) :color red)

Though probably I would prefer something more nested if possible, so you have a list of instructions rather than needing to parse them out of a flattened list. And I would likely use an alist rather than a plist for attributes like colour or stroke width.

Even superior:

    path 10 10 M 90 H 90 V 10 H 10 10 L #000 stroke

I know you're joking but I still don't understand why (+ x y) is a good idea: clearly the first argument has a different meaning than the other, IMHO +(x y) show better the difference between the operation a d the arguments..

That significantly complicates the grammar, as now nested function calls require context from their parent to form an AST node. S-exps are the literal representation of the AST which allows for easily modifying and inspecting code, for example through macros. It's not so much "the first element is significant", it's more like "this is the convention of what a function looks like so you can pass it around and modify it as a single list".

I'm only half joking. The different notations all have pros and cons, but the benefit of s-expressions are their simplicity. A list can be either an expression (+ x y) but can also be a list of things like (red blue green) and an empty list can be written as (). It is basically the simplest possible structured notation.

+(x y) would be fine for expressions but weird for lists of things.