Ready.
If you would like to load some operating-system to a USB flash-drive, SD-card (microSD, miniSD, SD), or a portable hard-drive (hard-disk), there are wishable, quite-necessary, seemingly trivial, but whyever, practically ignored-or-neglected abilities.
I know that platforms such as PortableApps and U3 exist, but they are not themselves (stand-alonne, self-sufficient) operating-systems, and when I'm looking for how some other platform or operating-system works (or, would work), those other existing portable-built platforms have little or no help. For example, as of May 30, 2016, there were three Zenwalk editions. The (non-USB, non-portable) hard-disk version was Zenwalk v8.0 RC1, the (DVD-burnable) Zenwalk Live v7.4 (& its curator had left the hobby/job, months, ago), and worse, the really wishable (loadable to portable-&-modifiable platform) was left at v5.2 (as far as Unetbootin could offer). So, how could PortableApps help (when I cannot install the operating-system), at all? At most, maybe we could have inspirations from such portable-platforms, for our wish-lists. By the way, if some of the wish items of mine, happen to exist in some of those, then either I have not heard (because I have not compiled anything for them), or I have forgotten having heard from there. That is, this being a wish-list (not a Ph.D. dissertation), I'm not postponing the wish-list (nor wasting my time) for a thorough "literature search" -- not to mention that, already, I have exposed various "Ph.D." theses which are practically nothing except plagiarism-&-banalities-&-"innovation"-as-absurd-degenerations/violations-of-basic-definitions-of-terms (such as the "works" of copycat82, minim93, etc).
Actually, that should be "no brainer" -- given that all that it takes, is presumably a boot-loader that does not change from operating-system to operating-system. In other words, if you are able to install some operating-system to your first-most non-removable hard-drive, then you should just include that little (USB-based) boot loader to that operating-system distribution, and the thing should work at USB flash-drives (& equivalently, microSD, & USB hard-drives, too). All should have been working like that, but no operating-system seems to have that sort of install option, so far as I know or remember.
Surely, while at it, a remedy against all sorts of troubles of absolute-links (the file-or-folder links that have absolute-paths, not relative-paths), does make into the wish-list, too.
Actually, that sort of trouble may happen to non-removable hard-drives, too. If you add some other hard-drive as your new "first" hard-drive, the former abs-links ("c:\..."), would have to re-locate (becoming "d:\..."). If already not at the first hard-drive, then if/when the first (or, any before this) hard-drive(s) become partitioned or de-partitioned, then re-locating of drive-letters would again become necessary. Not to forget to mention the regular trouble of simply copying a folder to other hard-drive, and then, if NOT ALL OF their internal links were relative-paths (such "purity" ("no abs") has its troubles, too, btw), then you have to re-locate the abs-links, again. Some utility (software) may help in such absolute-path-links-re-locations (but so far, I do not remember even such a trivial-&-necessary utility, out there), let alone the system suggesting you such re-locations (although (some?) spreadsheets do (or offer) that (similar logic), when copying or duplicating columns of addresses (& numbers)).
Actually, this does not happen to be "lethal" because one may work out various strategies through self-discipline, or script files (batch-files).
For example, (now I remember) a distribution of WinAVR meant for portable drives, tests (at batch-file) drive-by-drive, to find out at which drive itself is. (A trouble with that may be, if you have multiple versions of that, in various drives, & it finds some other copy of that keyfile of itself in one of the other drives.) Other method, how I tend to work out, is having a callable (script, batch) file that has the same absolute path relative to the root of its drive, that has all the settings (paths, environment variables optimized for that drive, for versions of software in there). That is, (drive-local) root-relative paths at hardware level, a combo of absolute paths and relative paths strategies.
Then again, now that almost any operating-system "distro" comes with its applications, then why not just compile them in ways that are portable-media friendly?
Presumably, many already refer to files through root-relative addressing -- but many simply don't. That is, seeing "c:\dir0\dir1\file.ext" more often than "\dir0\dir1\file.ext". BTW, if working-directory (current folder) could change, then (locating the) root-relative paths have risks, too, as in the case of WinAVR example I had just mentioned). If the software may autonomusly reset its work-directory to some other drive, then there is trouble. The shells (on Windows, "DOS prompt" and WinExplorer) do not have such habit of spontaneous jumps, but various (Windows) apps seem to reset or change from/to where they access files, for example. So, perhaps, they could, spontaneously, jump the pointer to working-directory from drive to drive, too?
Unix systems seem to refer to roots, but how/where they mount a directory, seems to be (if to choose a nice word, in questionable context) "flexible" (that is, not too dependable, if you are not self-disciplined, systematic). That is, the directory hierarchy is not necessarily reflecting the hardware, but "logical" configuration established at run-time. Actually, if you do that mounting right always (never changing the relative-paths), that would (presumably) work equivalent to the extra facilities I list as wishes.
Just compile the apps to consult the platform (operating-system) to tell on which drive they are working right now. The standard library may internally do that. If there is a likelihood of unplugging-&-re-plugging the drive/card while the app is running, then consulting the location of the root at every root-relative (in lieu for "absolute-path") access (to files or folders), makes sense. In other words, keep no string ("long-term buffer") that remembers the location of the root.
Alternatively, if for simply accessing a file/folder, then "knowing" the exact path-name (as a string returned from the system), is NOT necessary for that app. For example, file-open may have some flag for having access relative to the root-folder of the portable-media (in contrast to the root of the current working-directory). (Perhaps, PortableApps & U3 may have some such (or, some of the other) location-reporting, or access-providing?)
Alternatively, just how Windows has names for special folders (%WINDIR%, %HOMEDRIVE%, %HOMEPATH%, ...), one may just define (re-map) those names at boot-loader, for portable media, & perhaps "Live CD" do it that way, too, but perhaps (because they are mostly Unix systems), they just get away to the mounting hierarchy ("logical" organization), rather than having mappings to facilitate software to know the hardware addresses of special folders or files.
If showing pathnames to humans (or, logging-to-file, or whatever except file-access), then knowing the full absolute pathname is necessary, while at other times, it is sufficient to just make sure the operating-system understands that the intended file-access "relative-to-root" intends the root of the drive where the removable-media is.
As I have said, all of that sounds trivial to me (maybe because I had already known about such applicable strategies that exist here or there, throughout decades), but when it simply comes to finding some "distro" that just installs to removable-&-modifiable media, the thing simply looks as if "non-existent" or as if that were "hard" (given that few or nobody has taken that track) -- whyever.
I said I think installing at microSD is almost no different than installing at a resident/"permanent" hard-drive. In other words, unlike how a Live-CD/DVD has to "install" into memory, every time a session starts, MOST files of microSD remain intact, and boot-loading is almost similar to working from hard-drive, except maybe only the protocols (SCSI/IDE/... vs. USB).
Then again, sometimes, for example you may suspect that there may be some harmful software that may jump in if you plug that flash-drive or microSD into a computer (in public-places, or a virus-suspected computer of your own). In such cases, just locking the microSD, would work wishably. (I load the microSD(s) to computer through the SD adapter that comes with the microSD, & it has a lock ability, & if you plug that through some microSD-to-USB adapter, you may buy a lock-able one.)
Surely, I presume that there is no mechanical tool (robot arm) in that suspected computer, that unlocks your SD card, when inside. For that, you may have multi-levels, such as some miniSD-with-lock, within the SD-adapter, and I presume that the miniSD (as microSD is) at the outside/visible portion of the computer, & the locks of USB drives (& microSD-to-USB adapters) are at the outside, too, beyond the reach of "internal" robot-arms.
For that, the operating-system should NOT depend on modifying the "hard-drive" for starting to work. As long as a human is not requesting to modify something (a file or folder), the operating-system should never modify a thing for a session, at all. That is, after installing, the file-modifying option is not in the hands of the operating-system. Virtual-memory or other such optional-but-sometimes-necessary features will not work when the drive is locked, but that is all right, when safety is the main concern.
BTW, for virtual-memory, or other "optimistic" writings, one may have some extra flash-drive, next to the lock-protected main microSD. A fast one that is capable of boosting the operating-system performance, is preferrable, but not strictly necessary. Windows, for example, is informing about that, when the drive is not sufficiently fast for performance-boosting, but when all you want is a virtual-memory against impossibility of starting some extra apps, then a slow drive around may be a break-through.
The know-how (environment variables) may travel within token-attributes -- for example, at the index offset 0 of token-attributes of that node (normally, in E-nets (1970s), start offset was 1, but now (as I had thought in 2000s), [0] may refer to such extra, system-handle, or self-reflective suite of data for nodes). In other words, just "this" or "self" as in object-references (Smalltalk had self in 1970s, too, btw).
Such info-bag-@-start is a standard facility, for example, at [re-]start of android (operating system) apps (SDK-based apps, not necessarily NDK-based apps). If/when android thinks of re-opening your app, you write out the state/data of your app before closed, & after re-opened, read them back in). Nodes of a formalnet, are having their inbound data in the token-attributes -- if you would like to remember the state/data, in a loop, just modify them (such as counter-incrementing) when sending out the token-attributes (that is how E-nets (& perhaps any code-enabled nodes) had been working in 1970s, too).
One dilemma is to have the data as static (the index refers to the data that are loaded/marshalled at the back of the token-attributes list), which could cause stale pathnames (a trouble if the drive-letter changes at run-time), while the vice versa, is compromising from the self-sufficiency (the local-access, & distributed/traveling (in good sense) flexibility of the token-attributes facility -- as opposed to referring to global variables). A practical compromise is to have various authorities/roots that inform various channels, & a token-attribute may consult any of them (resembles how you verify your clock or weather-estimates, through internet, as there may be various data-aggregators, that in turn, refer to some clock-counters or weather-measurers). This does not have anything to do with what the formalnet-processor thinks. Just how you propagate the handle-to-authority(ies) (the closest to thisNode/self in the chain-of-authorities, if not multiple pointers/datasets) in the [0] or in whichever indexed location. That resembles how I write batch-files per hard-drive & USB-drive(s), I mentioned. For nodes that have nothing to do with the operating system, nor other remote access, the handle is optional.