I use a prompt that's similar to this (taken from the fish docs):

function fish_prompt
    set -l last_status $status
    # Prompt status only if it's not 0
    set -l stat
    if test $last_status -ne 0
        set stat (set_color red)"[$last_status]"(set_color normal)
    end

    string join '' -- (set_color green) (prompt_pwd) (set_color normal) $stat '> '
end

The relevant bit is that before doing anything else, the prompt reads the $status variable which holds the return code of the last command, and saves it to a local variable $last_status. Then it goes about constructing the prompt string, running other commands which overwrite $status in the process. It uses $last_status to conditionally show a red error indicator in the prompt.

When using this plugin, I noticed that failing commands do not result in this indicator being added to the prompt. I believe the issue is that _osc133_setup is running before the prompt, and overwrites the value of $status. I determined this by commenting out each of the functions in the plugin and testing the behavior; with _osc133_setup removed the status reporting works again (though at the expense of breaking some of the functionality of this plugin).

However, normally fish handles this situation (a function being declared with --on-event fish_prompt) correctly. For example, with the above prompt, if I then add this:

function greet --on-event fish_prompt
  echo "Hello!"
end

...then when I run false, I see this:

~> false
Hello!
~[1]>

Where the [1] is the indication that false returned a nonzero exit code. So even though greet is running echo which returns zero, fish knows not to let that override the $status value set after false exited.

So, I'm not sure why this plugin overwrites $status when the reduced example above seems to work fine. But maybe this info will be of some use if you feel inclined to look into the issue.