It's the only command I could find that tells me I'm running an Android app on a Chromebook, something I'm going to need soon.
Changes to the machine on Linux wouldn't affect the LiveCode Android engine - the Android engine uses the Build.MODEL which it gets from the Java Environment. Chromebooks are like Macs (as Android is) - the OS is tied to the hardware so one would hope that manufacturer provides a reasonable string for it
In regards to processor then Chromebooks come in both ARM and Intel flavours so its probably worth compiling using 9.5 with all Android architectures.
I'm still not quite clear what a better value for 'the machine' would be on Linux (or Windows for that matter) - both are OSes which can be installed on pretty much any 'PC' hardware. For it to have a similar meaning to iOS/Android/macOS (which is what you want in a cross-platform environment) it should be simple string describing the actual hardware the engine is running on... Not so much to do with hardware details but manufacturer/model etc.
Jacque's use-case is a good example - it allows her to distinguish between an Android phone/tablet and the Android (emulation) environment on Chromebooks. In that regard it puts it in a similar category (which is its intent) to the processor and the platform - it allows you to make decisions at runtime based on the environment in which your app is running.
It did occur to me last night that there is at least one Linux environment I can think of where it would be useful if 'the machine' did more than just return 'uname -m' (which looks like it is, unhelpfully, just the processor arch of the binary) - RaspberryPi (when we finally get a supported build). The latter is quite a specific piece of PC-like hardware and so being able to tell if you were running on one might well be quite useful. There might be others like that too... However one issue there is you are probably looking at a huge set of cascaded switch statements to determine what 'hardware' is actually underneath, even if identifiable.
Mark Wieder's suggestion of 'the detailed ...' is quite neat - although I really don't think lscpu is the right thing to be looking at - a machine is much more than a cpu. However, it probably would be a way to get more detailed processor information - although morally that should probably apply to the notion of 'the hostProcessor' rather than 'the processor' for reasons already stated.
At the end of the day, without explicit use-cases which people can demonstrate to be actually useful and guide what improvements could be made here then you are probably better off getting this info using shell("lscpu")... Which isn't exactly onerous is it?
P.S. I still offer the notion of hostProcessor to solve the OP's original problem - its 'just' a case of working out how to determine it in an atomic way on all the platforms we support.