But when someone tries to attack such a password, as long as whatever the user devised isn't represented by an entry in the attack dictionary, the attack strategy falls back to brute force, at which point a repetition scheme is irrelevant to attack time. Granted, if I were creating a repetitive password to meet a length requirement without high mental load, I'd repeat a more interesting part over and over, not a single character.

Sure. But most people add “111111” or “123456” to the end. That’s why it’s on top of every password list.

If cracking techniques catch the concatenation of those as suffixes to short undefined things, which I think many people would do at minimum, that would be worrisome indeed.

I would love to see most drop-in/bolt-on authentication packages (such as DotNet’s Identity system) to adopt “bitwise complexity” as the only rule: not based on length or content, only the mathematical complexity of the bits used. KeePass uses this as an estimate of password “goodness”, and it’s altered my entire view of how appropriate any one password can be.

IIRC the key point there is that it's contextual to whatever generation method scheme you used--or at least what method you told it was used--and it assumes the attacker knows the generation scheme.

So "arugula" will score is very badly in the context of a passphrase of English words, but scores better as a (supposedly) random assortment of lowercase letters, etc.

I'm told that at work we're not allowed to have the same character appear three or more times consecutively in a password (I have never tried).

Undisclosed minimum length is particularly egregious.

It's very frustrating when you've got a secure system and you spend a few minutes thinking up a great, memorable, secure password; then realize that it's too few (or worse, too many!) characters.

Even worse when the length requirements are incompatible with your password generation tool.