Contrary to my previous posts, there might be a strong reason to keep the kernel's current built-in table, and adjust loadkeys+ckbcomp to match that.
The kernel's bulit-in table matches the behavior of at least two popular terminals: pterm (putty) and urxvt. Shift-F1 generates \e[23~ etc. (unlike after a loadkeys+ckbcomp when Shift-F1 becomes \e[25~). With these terminals (Linux's hardwired default, putty and urxvt), combined with the corresponding TERM value of linux, putty* or rxvt-unicode*, terminfo's 'kf13' etc. keys are defined with off-by-10 semantics; whereas for most of the xterm-like terminals terminfo defines them with off-by-12 semantics. Notice that the problem already exists with putty and urxvt, independently from the confusion in the Linux kernel vs. loadkeys+ckbcomp. Honestly I have no idea how someone is expected to handle the shifted function keys using terminfo, having no information whether the keys describing them are indexed from 10 or 12. And apparently I'm not the only confused developer. To which the short-term solution is to avoid terminfo and hardwire a handful of potential escape sequences. Which approach, if the console is off-by-2 compared to putty and urxvt (as it is after loadkeys), it is super prone to the shited function keys being interpreted off-by-2 in one or the other. The developer would have to check the TERM value and based on that choose one of two conflicting lookup tables. It would be definitely safer, more reliable if at least these terminals agreed on the sequences they sent. Which would mean to keep the kernel's built-in table as-is, and adjust loadkeys+ckbcomp. Resulting in folks getting angry because then they _again_ cannot tell F11 apart from Shift+F1. I think the only true way out of this mess is to switch to some completely different escape sequences (maybe \e[1;2P ..., \e[15;2~ ... as used by xterm).
