CaseInsensitive is a negation, and so less clear.

The self-evident way here is to use named parameters (now a D feature):

    str.replace("USER", user, caseSensitive : true);

Good point: named arguments/keyword parameters actually do negate some of the need for this. Qt is obviously designed for the limitations of C++, so this definitely makes sense. (And yes, CaseInsensitive is not necessarily ideal either. That's a fair point. But, given the limitations, I definitely see why they picked that route.)

However, I will say one thing: there is another good reason to consider using enumerations in place of booleans, and that's when you have a situation where you are not 100% absolutely sure that 1-bit of information is sufficient. For example...

A bit contrived but, let's say you have a method that can optionally perform some kind of validation, like let's say, in C syntax so I don't embarrass myself, you have something like this:

    void process_request(request req, bool validate);

This works well, although it obviously fails to the boolean parameter trap. But in D, you can avoid the boolean parameter trap, so that's not too big of a deal. However... I think that in many cases, boolean values are used in cases where you just happen to have something that only has two options, and not necessarily something that is true by nature. For example, maybe you want a validation mode where you only log a message but do not halt processing upon validating. Something like this could work:

    void process_request(request req, bool validate, bool allow_invalid);

But there's a lot of ways you could go about trying to name allow_invalid, it's arguably a pretty bad name. Worse, it only really makes sense when validate = true. In my opinion, something like this would be better:

    typedef enum {
      NO_VALIDATION = 0,
      VALIDATE_AUDIT = 1,
      VALIDATE_ENFORCE = 2,
    } validation_mode;

    void process_request(request req, validation_mode validate);

For case-sensitivity, maybe it's true that this is not necessarily important. However, for regex options in particular, I think what you MIGHT want is more like a set of flags rather than either a pure enumeration OR a pure boolean. Of course, at that point, it does beg the question if maybe regex options should go in their own options structure of some kind, at which point boolean would make more sense again, but at least for shorthand, having a simple flags option seems reasonable to me. (I haven't checked how Qt does it currently. I would not be surprised if they have a longer form "options" overload, too.)

But the enum is equally clear and less typing. If you want named parameters just so can reorder arguments the enums can all have different types and thus the language can reorder (if that is a good idea is an open question)