Maybe I should deploy this Unicode processing, assuming for the moment that the algorithm would effectively strip the decorations?

Decoding confusable characters sounds like a neat feature, but I'm undecided whether it's worth the disk space for the character equivalence table. I feel that for --restrict-filenames it would be more in its spirit to just strip everything with codepoint >= 127. Might be overreach though, thus my idea of using the ranges from zalgolib.

Everything with codepoint >= 127 is stripped and replaced by _, which explains your example output. You're suggesting that the Unicode codes representing decorations be dropped instead, no?

My hope was that the confusable remapping would also strip the combining decoration codes, and then any resulting non-ASCII codes would be mapped to _ as now. I'll try this out when I get a chance.

Indeed confusable processing doesn't make any difference.

But this apparently reasonable change (skip Control and Mark codes) in the replace_insane() local function does:

         if restricted and ord(char) > 127:
-            return '_'
+            return '' if unicodedata.category(char)[0] in 'CM' else '_'

Then the filename as above is Film_Theory_-_There_Is_Only_DAD_DaD_DAd_daD_dAD.

I don't understand enough details to comment on the implementation, but the new output looks like it solves my problem. 👍

The logic uses the General Category assigned to each Unicode code point (https://en.wikipedia.org/wiki/Unicode#General_Category_property). The Major category (L, M, N, P, S, Z, C), indicating Letter, Mark, Number, Punctuation, Symbol, Separator, or Other, is the first character of the category name (all two-letter values). I made the executive decision that for code points above 127 Marks and Others (eg, combining marks) should be omitted rather than mapped to _ for --restrict_filename.

Fortunately Python offers us the unicodedata library module to help with this, so it's a (less than) one-line change.

While you're at it anyway, would it be cumbersome to have an option to use a custom character instead of underline?

I'm inclined to think that it would be, unless you have a very compelling use case, especially since this option exists only to help file systems that don't understand Unicode (so there isn't a large choice of alternate characters).

There are utilities, depending on the platform, that could be used with --exec ... to rename downloaded files.

yt-dl could acquire some of the output template formatting enhancements from yt-dlp, which includes a string replacement syntax. I would favour that over a custom option, but it involves a lot of code to replace/extend the built-in Python formatting syntax currently used.

Yeah ok that indeed sounds too cumbersome. My benefit would have been to simplify the renaming tool I --exec but I see now that the impact on your codebase here would be disproportional.

Thanks! 👍