Jonathan Rascher

Thanks for this change! I tested it out with my userspace, and here are my findings: 1. The `userspace-add` and `userspace-remove` changes seem to work as expected. Here's the `qmk.json`...

Sure, attached (and renamed to make GitHub happy): [parallel_kb_builds.mk.txt](https://github.com/qmk/qmk_firmware/files/13908574/parallel_kb_builds.mk.txt) If I'm reading this correctly, `FORCE_LAYOUT=foo` is getting passed along at least part of the way. I wonder if now I'm...

Random side note: Without understanding the underlying implementation details, as a user I feel like it would be nice if layouts were more a "first class" concept in keymap selection....

Sorry for the delayed response! Agreed, although `userspace-compile` doesn't _say_ it's using the correct layouts, the output file names seem to confirm that it is: ``` $ qmk userspace-compile -c...

> @bcat any luck on confirmation? Sorry for the long delay! Yes, I've flashed the firmware files built with this PR and they seem correct to me. Thanks again!

Note that I think this is distinct from https://github.com/qmk/qmk_firmware/issues/22815. That issue seems to be about the existing ability to pass force layout to `qmk compile` not working, but even if...

Ah, yeah, that would address my use case, and it's more flexible too.

Not stale, and has a fix in flight. Thanks @tzarc! :)

Still not stale, and I can confirm PR #22887 seems to work (though I haven't pulled in changes from HEAD for a little while).

Oh, fascinating to read this. I ran into the same problem, and IIRC, the same issue happened to VMs too. It's just that they take a little longer to start...