It should also be possible to force a limited character set; alpha-numeric, no Unicode; but I doubt that would be popular.
Heh, that’s like asking “Why do I get wet when if I get caught in the rain?” – The short answer is that you probably didn’t anticipate that it was going to rain; didn’t check the weather report; didn’t bring an umbrella; etc.
Historically, software is always written with an “oops” factor – “Oops, we didn’t think we would need that”.
I’m pretty sure it would not be.
This is something like how I did it for my GUI database program on the Commodore 64. It would check keypresses with a sort of “look-up table” and discard “illegal” ones (also remembering the count so the delete (backspace) stopped where it was supposed to).
It would be interesting to see if such a system could be implemented, for new users anyway.
These can’t be Brits, then 
Don’t take my comment so literally, it was more cynical than practical.
That said, it might avoid the complication. I mean, you can still create a viable passphrase without Unicode, and if it were as simple as limiting characters in the passphase input, that would probably be workable.
(But) I don’t know if it is that simple, as Calamares would possibly need modification, and Calamares devs would likely indicate this isn’t their problem (and they’d be right).
Other factors are also not so obvious to someone who has never used anything other than a US keyboard.
My opinions only, without any research performed.
I tend to do that, don’t I. 
But it’s a GOOD idea, to limit what characters can be used, unless the user chooses to enable “special” ones, to avoid these sorts of “teething troubles”.
You’d need to limit the character set to the lowest common denominator of all possible keyboards.
… not a good idea, I think - if even possible
Perhaps an option to create and store a key on an external device (usb thumb drive),
to ensure the system can be booted and then whatever changes need to be done can be done?
… too complicated - a warning with explanation should suffice
This indeed may be a better option for people wanting to keep their laptop “secure”. But make sure to have a spare USB or two in case the first one fails, or an easy way of creating a new one.
… or indeed just the first one, initially - the machine would need to have a second free usb slot
the first one is already used by the installation medium and not every device has got a second one
again: too complicated
Even two is too few! And mine need a bit of maintenance now. Just one though, ugh. Only way round that is one of those USB hub things.
For some people, a PIN-type passphrase (a long one) might be a better idea? But I think I’m out of ideas here. 
Are there any Arch-based distributions handling this any better? I haven’t been interested enough to experiment with any, apart from Manjaro, but if someone is ‘getting it right’, might it be worth looking at those options?
It’s all supposedly open source, after all.
Quite some time ago now there was Archlabs, desktop based on the openbox WM.
Inspired by Bunsenlabs, which was based on Debian.
I think it doesn’t exist anymore.
(I just looked - it does, but different than when I used it years ago)
It had a text based installer which could handle the scenario of unencrypted /boot
It doesn’t. – also, the download for the final version seems to be compromised.
However, I have archlabs-2022.10.15-x86_64.iso sequestered away on a bluray data disk somewhere. I can likely make it available at a later time, if it’s useful.
It looks like it can be had from here.
Not as an iso though - but instructions on how to build it.
The installer might be worth a look?
But I doubt that Manjaro would abandon Calamares in favor of this.
In my previous comment a link is provided on how to generate a custom grub efi stub with a custom keymap included.
When using systemd the table mkinitcpio - ArchWiki provides insight in where the hooks are most useful.
My laptops boots using signed efistubs and Plymouth 24 to provide the a GUI for the descryption phrase.
No, and that wasn’t suggested; but seeing other implementations in place can sometimes be inspiring.
I recall seeing vague murmurs here and there that Manjaro should take this route (systemd boot), and it’s apparently a faster (and cleaner) process overall.
Have you heard of any serious consideration being given to this perhaps at a later time?
I would also like to add → a default ESP size of 10 GB would be recommend for any bootloader of user’s choice.
Not sure, if users want some features in future:
All of these are stored in the ESP without Grub. Therefore, a smaller ESP size of less than 1 GB could pose problems.
Well it does work just not in an intuitive way, the same thing bit me when I encrypted my disk.
It wasn’t until I reinstalled after thinking I’d mis-typed the first time that I tried using the shift key alternatives and they worked.
It’s kind of annoying at first but typing is muscle memory so switching shift+’ for shift+4 isn’t a huge leap.
That sounds a bit excessive. My system currently has 512M for /boot and contains all the kernels with plenty of space for more (this isn’t an Ubuntu-based system!):
ls /boot
grub initramfs-6.6-x86_64-fallback.img linux61-x86_64.kver memtest86+
initramfs-6.1-x86_64-fallback.img initramfs-6.6-x86_64.img linux66-x86_64.kver vmlinuz-6.1-x86_64
initramfs-6.1-x86_64.img intel-ucode.img lost+found vmlinuz-6.6-x86_64
…. 10 GB?
My ESP isn’t populated but the reserved partition space is ~128M, in case I decide to convert this installation to EFI boot.
512M won’t be sufficient if users want future features like:
I use a snapshot booting solution that contains many different kernel versions without kernel fallback in my ESP without Grub, and 1 GB is surely not enough in my experience.
$ du -sh /boot
1003M /boot
EndeavourOS, CachyOS and others have configured Calamares in a manner that allows the user to choose the bootloader.
systemd-boot only support EFI systems - I think that is the primary reason there has been no discussion within the team on the choice of bootloader.
I don’t think a refactor of how Manjaro has configured Calamares is going to change any time soon - but one can never know - especially not me - I am only a minor voice on the team.
The support for systems using MBR or BIOS/GPT, grub support for btrfs and btrfs for immutable also calls for some of the advanced features of grub loader.