I'm posting here because I have nowhere else to post. If you squint, this meets the community rules because my current keyboard is a Piantor/42, and my issue stems from a combination of 40% and QMK behavior. Although, to be honest, this is mostly about QMK, but using Discord is painful, and I'll go there only as a last resort.

For a long while, I used Kanata on my laptop, and desktop an ErgoDox, having replaced kmonad because of one certain feature: tap-hold key sequence behavior. It's best described here, but the tl;dr is that (press lsft) (press a) (release lsft) (release a) where a is a tap-hold key should output "A" and not "a" -- kmonad outputs "a".

A few months ago, when I got my Piantor, I discovered that this sequence outputs no character, and although there's an option that makes it output "a", I can't find a combination that makes it output "A". I'm asking whether, in the bewildering set of QMK variables, is there a way to configure QMK s.t. the sequence (press lsft) (press a) (release lsft) (release a) outputs "A"?

That's the main thrust of my question. As a sort of addendum, I think this behavior is behind another of my QMK irritations: I'm a reasonably fast typer, and often will be typing the next key before I've completely released the previous key. This means I have to set a large-ish time-out before tap-hold engages, which introduces an annoying delay whenever I want to chord a layer and get at, e.g. numbers. I do understand that this is may be an unsolvable issue, that it's just an unavoidable limitation on small keyboards in having so many common keys (numbers, punctuation, and arrows are the worst -- coding, nearly half the text are characters from layers). Either I have a long timeout and and live with an annoying delay when I want to type (many) punctuation characters or numbers; or I have a short timeout and frequently accidentally shifting layers. However, I feel as if this might be mitigated somewhat with the Kanata-style key sequence handling, because even though my Kanata configuration is nearly an exact mirror of my QMK layer configuration, I never have this problem with Kanata.

I suppose I could give up on using QMK for anything except the most fundamental mapping, and use Kanata instead. However, there's an appeal to the portability of having the programming in the keyboard itself; it makes me a little less dependent on the computer to which the keyboard is attached.