@Andreas_Hegenberg Have you recently changed anything in the key sequences? My text expansions are acting confusingly. Example:
“dt” is supposed to expand to “Devonthink.” It does.
But “DT” also expands to “Devonthink.” It shouldn't.
“sc” and “SC” both expand as well. But only the lowercase letters should.
“fi” expands to “FI”
The dt example:
dt --> Devonthink.bttpreset (4.0 KB)
I don't think anything changed. The dt one you shared would trigger in both cases because that part of the key sequence looks the same regardless of whether shift is pressed before or not.
Really, I never noticed that. And there's no way to change it?
You could add an advanced trigger condition like this to it, so it wouldn't trigger while holding shift:
I'll check whether anything with the sub-sequence matching changed, I can't remember anything but it could be a subtle change.
Yes, please. I'm almost certain it used to work differently. Otherwise, I try the condition.
But for me,
R space space
and
r space space
trigger something else. How is that possible?
The problem for your key sequence above is most likely this NOT being checked in the one sequence but it is probably checked in your other key sequence that contains shift. Is that possible?
That makes the lower case sequence complete one event earlier: it can fire on the second Space down. The shifted one only becomes complete on the second Space up.
I'm not sure I understand. In any case, whether “key up” is checked or not, “dt” triggers with both uppercase and lowercase letters.
The example with r/R space space ... I see now that the sequences are in a CAG and trigger in different text fields.
This seems to make a difference. The uppercase letters no longer trigger. But unfortunately, I don't understand why.
It is important to understand how key sequences are being recognized. Example with two sequences that should make clear why the required checkbox makes such a big difference with otherwise same sequences:
Key sequences:
1.) shift down + d down + d up (required)
2.) d down + d up (not required)
Key being typed:
1.) shift down => nothing happens, but first key in first sequence is matched
2.) d down => key sequence 2 triggers because the only required key (d down) has been matched
Next example
Key sequences:
1.) shift down + d down + d up (required)
2.) d down + d up (required)
Key being typed are the same again:
1.) shift down => nothing happens, but first key in first sequence is matched
2.) d down => nothing happens, but second key in first sequence is matched and first key in second key sequence is matched
3.) d up => first key sequence triggers because now all of its keys have been matched. The second key sequence is also matched now, but the first contains more matched keys, thus wins.
Okay, I’ll think it over more carefully when I’m awake. For now, the only important thing is that there’s a simple solution: just check the boxes 
Thanks, Andreas.
But that doesn’t seem to be entirely trivial, even for you. After all, you suggested a different solution at first.
Sometimes a creation even outgrows the master who created it. I think that speaks for the creation …and the master … somehow 
hehe, I only had your one key sequence to look at, thus it was not easy to guess what might be different in your shift-based one. But yes these things can get complicated!
This gave me an idea, next version adds a visualizer for easy debugging of such behavior.
The first video visualizes the issue you encountered here (non required keys have dashed borders):
//edit visualizer is now available in 6.355!
