I was actually thinking of this as a solution (albeit late) for mayura as it should work already in the current version of Keyman. At least that is how I understood the documentation you provided a link to regarding virtual-keys. At the very bottom of that page it states that “Any key can be used to switch keyboard layers” and then lists 5 layers with values 261-265 (AltGr being 265).
So, I’m assuming that CapsLock can be ignored (as described on the other page) and can be used to switch to the AltGr layer.
However, the topic of additional modifier layers is one that I’ve developed a personal interest in.
I also predict that there will be an increasing demand for multi-script keyboards- not just the ability to relatively easily switch keyboards. Much like the Japanese (and Korean) keyboards. Thanks to what Unicode offers in terms of facilitating mixed-script text combined with globalization which is quickly reaching and beginning to transform every remote corner of the planet, it seems inevitable to me that we will begin to see more and more mixing of multiple writing systems, not merely in the same document but within the same paragraph and even sentence. Especially with Latin being one of those; particularly in regions whose official/native languages are written with a non-Latin scripts. There are numerous reasons for why this will be more and more commonplace. Switching keyboards in these instances, will be cumbersome and I foresee that users will prefer and seek other options.
The most logical and obvious of those, in my opinion, will be to re-purpose the Caps Lock key (which has fallen into disuse by the new generation at-large; even when typing in all caps for the most part!). It is particularly suited to the task because it even has an LED indicator on most keyboards, and this functionality is also quite intuitive: it momentarily (with LED reminder!) reactivates the original, native functionality of the underlying hardware. And it actually natively supports (at least) two states—the base layer, and the standard shift layer—exactly like the underlying hardware. Windows only supports separate mapping for CapsLock and CapsLock+Shift; but Mac allows a complete doubling of any/all modifier states and *nix-based systems with XKB offer even more robust and creative mapping options).
While this may not immediately seem intuitive to many computer savvy adults, my anecdotal experience and informal research shows me that newer computer users whose native languages use non-Latin scripts, as well as the younger generation of the West who generally ignore CapsLock do in fact find this alternate re-purposing of Caps Lock to be very logical and intuitive—because they have no prior experience or information which contradicts such functionality.
However, this particular capability does not seem to be particularly easy to implement with Keyman. Actually, if I’ve understood the documentation correctly, it may not be possible at all to duplicate this functionality.
And that is actually a feature which I intend to request, because I think it is — or at least will become — a serious deficiency of Keyman (that is unless I’ve misunderstood the documentation-I didn’t see any explicit confirmation that it is possible to have a unique layer not only for CapsLock—separate from the base or shift layers—but also an additional layer with CapsLock AND shift which is also unique from the base layer, the shift layer AND the CapsLock layer. If that explicit confirmation is indeed present, I somehow missed it or it was not on those particular pages. If it was assumed to be understood as “implied” or “obvious”, I would assert that while such an assumption is presumably reasonable for someone who has a background in IT and/or software development, this is actually not, in fact, sufficient for the average end-user; even a fairly savvy power-user).