Here's one emulation related question that I have had for a long time:

Suppose I want to emulate some system running Linux. In this case, what CPU architecture would be best to emulate?

Here are the constraints:
* No access to hardware virtualization on the host, so the CPU will necessarily have to be emulated, even if the architecture is the same.
* Must be able to run an official release of the current stable version of Debian (buster at the time of this post). In particular, this should be one of the main supported architectures, and not one of the community maintained debports.
* Typical hardware, like a display, keyboard, ethernet adapter (with a functional Internet connection) needs to be emulated.
* The emulator must be open source. (I'm thinking QEMU here.)

So, in this situation, what sort of system/CPU would be best to emulate?

Depends what you mean by best. You're going to have the best selection of older software with x86. And likely the best available Windows software via Wine. The best selection of newer software is likely with AMD64. But, if you're thinking about it in terms of performance, I have no idea.

For this purpose, I am not bound to any non-portable software (and, in particular, no software for which source code is not publicly available), so any reasonable architecture should suffice. In particular, no Windows software will need to be run in the emulator.

Given your requirements, the answer is obvious: don't emulate. I don't see any valid reason to emulate in all of your post. If you just want a random other architecture to play with, asking which is "best" is pointless, as well: just pick one that works. Even the practical suggestion of picking the one that's fastest is irrelevant, since I have no idea what you'll even be doing in the emulator (MIPS in the same endianness as your host is probably the easiest/fastest, but that's just the CPU). You will probably be able to boot any of the Buster supported machines in qemu with a little effort. which is your best bet on an emulator that works and is well-supported by its development community (even if it isn't necessarily the best emulator for your unlisted requirements).

I used to run multiple real, physical machines with different architectures, supposedly to test as compiler targets. I never got around to that, and anyway, all of those architectures are dead now; debian doesn't even support them any more. x86-64 or ARM are the only useful architectures to target.

AnLinux and/or "Limbo x86" might be what you're looking for, both on F-Droid, but I don't use them myself (not even sure why I have them installed, but it's not the only crap I have installed I never use). You might also want to see if fuse is available on your device; apparently modern Android uses it internally. However, they may just insert the module when needed and then remove it so normal users can't use it. My phone, for example, has fuse support enabled, but I don't have any fuse filesystems on the device to test it with, and don't really care that much.

I have no need for Linux on my phone; I stopped caring about that when my Motorola A780 was stolen (pre-Android). There just isn't any point, as far as I'm concerned; I just use my laptop if I need computing on the go, and I have no data plan on my phone. Tablets that can't run Linux directly are just garbage to me. If you had listed this use case in the OP, I would've just ignored the entire thread.

From what I understand, fuse is used internally by the system, but the device permissions are locked down so that normal apps can't access it without root.

Limbo x86 might work, but I believe it can actually emulate more than x86, so that still brings up the same question of what architecture is best to emulate.

AnLinux isn't really an emulator; it really just uses a program called proot to fake enough root capabilities in order to run a conventional GNU/Linux distro. Things like mounting disks is not going to happen via proot. (I have played with proot on a GNU/Linux system; it is a nice program (I can, for example, use it with qemu-user to run apt on a Raspbian partition from an x86 computer, handy if I need to update the software before putting the SD card in an actual Raspberry Pi), but it does have its limitations.)

Another use case you might find more interesting: Suppose I need to do this sort of thing on a school or work computer, I am not allowed root on it, and for whatever reason virtualization extensions are not available. (If I did have to do this on a regular basis, I would probably need to ask the admins to give me root or enable KVM, but for sake of this discussion let's assume the admins are idiots and refuse such requests even if I need to do this for classes work.)

Or another: The device in question is a Raspberry Pi, hardware vrtualization is not available (it's apparently *possible* to do it on the 2 or later, but not as straightforward as it should be), and I need to test new kernel features without risking making the device not boot.

A third case would be if the device is actually a VM, perhaps one of those VPSes that can be rented (though, in that case I could probably look for an x86 and use user mode linux there). Or worse, if it's just a container (rather than a full VM) that's being rented, in which case the loop devices would not be available.

By the way, speaking of tablets, do you know of any way to get a tablet with a physical keyboard in a manner that it can be used without a flat surface? (The case with keyboard I have for my old cheap tablet is not suitable, as it is not rigid enough for that use case.) I would prefer something around the size of 7 or 8 inches; anything bigger and I might as well just use my laptop.

Sorry, I just can't get behind using an emulator for any of the uses you describe. It just seems like hitting a thumbtack with a sledgehammer. When I'm on an inferior machine, I prefer to use ssh, remote X, or VNC to access/use a better one instead (where "better" doesn't necessarily mean faster). If I use an emulator at all, it's to emulate the inferior machine so I don't have to do development and testing on it. I'll just leave it at that.

Well, other than to admit that fuse needs a setuid fusermount to work, and I guess Google doesn't want that.

And to say that even though Limbo x86 uses qemu, and supports a few additional architectures (but not all of them; in particular, my suggestion of MIPS isn't supported), the version on F-Droid seems limited to x86/x86-64. You'll have to build it yourself or trust an apk repository if you want more.

Also, I have no idea about your keyboard question. Have you tried gluing a metal plate or something else thin and stiff to it? I mostly just use bluetooth networking with my laptop to access mine via ssh when I need to do a lot of typing. The only time it mattered was when my laptop was dead for a while, and I just lived with its quirks then.

Of course, being able to ssh into a "better" machine (which I'll assume means a computer that you have root on or that can run VMs with hardware acceleration), this would require one of two things to work:
* A network connection one can use to connect to the machine in question (and, depending on one's phone plan, one might need to worry about data plan charges)
* Another, "better" device, that would need to be carried around, like a Raspberry Pi 0 W and a power bank for it. Thing is, purse space is limited, so one would need to be able to justify it. (Have the 0W act like a wireless access point with a known essid and encryption key, then use keys for ssh login, and this should work reasonably well, assuming the "worse" machine at least has ssh and wireless.) I haven't been able to get bluetooth to work well from Linux. In particular, the simple (or should be simple) task of sending a file from my laptop to my phone is something I was not able to accomplish. The bluetooth system on GNU/Linux is not user-friendly.

Any advice on doing this? (One constraint: I need this done without Xorg or Wayland running.)

(It's also annoying that bluez requires dbus; for some of the simple systems I like to play with (like buildroot etc.), I would prefer not to have the added complexity of dbus in the system.)

You're making a lot of assumptions about being able to run whatever software you want on the lesser machine, as well. In particular, "work/shcool" computers tend to either be freely accessible enough that you can just run like you're root, or the exact opposite: so locked down that you can barely even browse the web or preform other "common" tasks. Lesser computers also have a tendency to have less storage space. That's an understatement. Mostly undocumented crap that refers to the standards as if everyone has them memorized that has recently (4.x->5.x) been to converted to undocumented almost unusable crap over dbus (as you already mentioned) and tightly integrated with systemd (which I don't use). I guess common tasks are GUI-fied, so nobody cares that it's not documented.

I never use the GUI unless I'm stumped and hoping the GUI will do some magic I don't know about yet. I use bluetoothctl for pairing, force connect, force disconnect, and misc other stuff. It has a help command. You might need "power on" to first power up your controller You'll also need to have it running with its agent on (agent on; default-agent) to confirm/send passcodes.

My tablet runs Linux, so I can make it act however I want. In particular, I use bt-network (from bluez-tools) to run a nap network. On the tablet (server), it's set up using /etc/network/interfaces.d/bt (it's Devuan, so it's Debian-like; requires bridge-utils):
>iface br0 inet static
> address ....
> netmask ....
> bridge_ports none
> post-up bt-network -d -s nap br0
> pre-down killall bt-network

On the laptop (client), I connect using bt-network -d -c <bt-addr> nap & and then wait for bnep0 to come up and configure it with an address (all scripted, of course). There are other options, but all of them are unreliable on my systems. bluez-tools isn't very stable.

Your phone is probably more limited. I assume obex is what you want, which I have no experience with. I just use USB with simple-mtpfs. A quick try with my laptop and phone shows that bt-obex (also from bluez-tools) crashes on ls. On the other hand, obexftp (both as a client and as a fuse fileystem, packaged separately as obexfs on Debian) seems OK, but I'm having a hard time keeping connected long enough for serious testing. It's probably something I'd need to do on the phone side to keep it from disconnecting right away. You might also have better luck running an obex server and using a client on the phone.

Anyway, it's pretty obvious that I have no idea what I'm doing most of the time. My DualShock 4 suddenly stopped connecting immediately one day, requiring a partial re-pair every time, and now it's working again. I have no idea how to even anallyze what went wrong (other than knowing that it was some sort of service negotiation failure): bluez just doesn't seem to log anything anywhere (possibly because I'm not using systemd). You could see if you can get bluez-4 working. On the other hand, a basic dbus setup on its own isn't that heavy, and might cure some headaches in the future.

If you are able to run a modern-ish web browser on the lesser machine, you might be able to run something like "shellinabox" on the computer you have root on, and access it through the web browser on the more limited machine.