It's on purpose.

It's done here:

It is performed when --no-restrict-filenames is set (the default), just adding fee0 to the basic latin codepoints to get the codepoint of their fullwidth forms. In the case of --restrict-filenames it would just delete it, which is worse.

There isn't a way to disable it, unless you edit the code (change what chars are affected by the fullwidth replacement in the loop, or remove all calls to the function). Maybe we should get a new option that disables sanitization to the bare minimum (only disallowing forward slash and allowing everything else). I don't mind it personally because the title is fully preserved in the accompanying metadata (embedded and in info.json).

Alternatively you can use --compat-options filename-sanitization to mimic youtube-dl's behavior which doesn't do this

git-blame says this added it 989a01c

Maybe we should get a new option that disables sanitization to the bare minimum (only disallowing forward slash and allowing everything else)

We are doing the bare minimum sanitization, except that the code doesn't know what characters the filesystem allows. So we sanitize for the most restrictive. If you know of a way to correctly identify what characters need to be sanitized, let us know in #4547

Duplicate of #4767 and related

Summary of all solutions:

1. Use --restrict-filenames if you don't want any special characters
2. Use --compat-option filename-sanitization to use youtube-dl's behavior
3. Use --replace-in-metadata to control how each character should be replaced

Ok, that makes sense why it's on purpose. (also I apologize for not seeing #4767 I looked for probably 15 minutes accumulatively and could not find anything)
I thought that this was a YouTube specific thing though, because I downloaded a video from BitChute, and (I thought) it used non-full-width characters... but I tried again, and it does... oops.
Thanks for the help!

I looked for probably 15 minutes accumulatively and could not find anything)

No worries. Github issue search sucks unless you know the right search terms. But now that this issue is pinned, hopefully more people dont make duplicates

Although this is closed, I wanted to add information.

None of the above options (delete, make fullwidth, or make underscore) seem reasonable to me.

I thought I could tell yt-dlp to ignore certain characters by simply replacing them with themselves in metadata, but that produces an error.

I am currently working around this problem. I allow the default (fullwidth) option, which at least preserves the information about which character WAS there, so I can put it back at the command line, with things like:
for f in *？*; do mv -v "${f}" "${f//？/?}"; done
and
for f in *＊*; do mv -v "${f}" "${f//＊/*}"; done
(I didn't really test this, and it might have problems with quotes.)

My ideal would be to allow the user to specify a string containing all the characters they DON'T want yt-dlp to help with.
(Edit:simplified a bit)

The replacement of '"*:<>?|/\\' with their full-width variants is awful on Linux, especially when using the command line and scripts to archive videos.

As there doesn't seem to be an option to disable this, the following can be used instead:

sed "s/return.*0xfee0.*/return '_' if char == '\/' else char/" -i .local/lib/python*/site-packages/yt_dlp/utils.py

or if you want to replace / with its full-width version instead of a _ this can be used:

sed "s/return.*0xfee0.*/return '\\\uFF0F' if char == '\/' else char/" -i .local/lib/python*/site-packages/yt_dlp/utils.py

or the "big" /:

sed "s/return.*0xfee0.*/return '\\\u29F8' if char == '\/' else char/" -i .local/lib/python*/site-packages/yt_dlp/utils.py