Here is my configuration:

$ sh -c 'env HOME=$(mktemp -d) fish'
Welcome to fish, the friendly interactive shell
Type help for instructions on how to use fish
$ fish --version
fish, version 3.3.1
$ echo $version
3.3.1
$ uname -a
Linux Gacrux 5.10.0-10-amd64 #1 SMP Debian 5.10.84-1 (2021-12-08) x86_64 GNU/Linux
$ echo $TERM
xterm-256color

Here is a minimal working example:

$ argparse -i 'h' -- '-o a' -h
$ set -l

Obtained output:

argv '-o a'  '-h'

Expected output:

_flag_h -h
argv '-o a'

(Note that the output is as expected when '-h' is given before '-o a'.)

Here is a use case. I have a function, that call a command, say cmd, which accepts options. My function allows a user to pass some options to cmd, by using the -c option (of my function) which takes one argument, namely the string of options to pass to cmd. Before parsing the option of my function, I want to consider printing help, so that it will be successfully printed even if a wrong option is in used (I like to do my function this way). My code (assuming the command cmd):

$ function myfunc
      argparse -i 'h/help' -- $argv
      set -q _flag_h
      and echo "Usage: myfunc [-c OPT4CMD] [ARG...]"
      and return
      
      argparse 'c/cmd-opt=' -- $argv
      or return
      
      cmd (string split -- ' ' $_flag_c) $argv
  end

(Of course in this simple example, there is no real need to write the function.)

My test showed me that actually an argument starting with '-' but containing a space is still considered as an option. This is the case for several fish buitlins, such as string for instance, but not for others, such as echo.

$ string split ' ' '-s a'

returns an error (code 2) with message (stderr):

string split: Unknown option “-s a”

(Type 'help string' for related documentation)

while

$ echo '-s a'

just successfully outputs

-s a

Would it not be more reasonable to never consider an argument starting with - as but containing a space (or other special characters) as an option?