> The answer everyone else is using is to add an operating system and an application language as a starting assumption, and then slowly grind through every issue caused by giving up control at the base layer to these more automatic systems.
The OS community generally understands in theory, although this is much less accepted in practice, that mechanism and policy should be separated as much as possible. Forth, operating systems, Smalltalk, etc. all converge on making programmed systems, if in substantially different contexts, and this becomes a question of layering abstractions. A Forth-like OS that would solve your problems is related to microkernels and exokernels. Minimality and simplicity is essential for foundational services.
1. I want to debug my assembly code with a REPL
2. I don't want abstraction, I want minimalism
3. I want to write solutions in the context of specific hardware
When you have all three, you have Forth's wheelhouse. Minimalism means you do get a sense of "seeing the Matrix" - the machine is controlled precisely to your specification. But as soon as you think that you can layer on a more abstract idiom, even those that are usually conventional in high level programming, it also reveals that it really won't help you do that. Either you DIY that abstraction, or you revert to the same load-store imperative paradigms you'd use for a large assembly program.
The answer everyone else is using is to add an operating system and an application language as a starting assumption, and then slowly grind through every issue caused by giving up control at the base layer to these more automatic systems.
I think there is a reasonable place for Forth as a runtime target for compiled code, but the style of code that it supports prefers "flat" designs, like dataflow/FBP languages, because of the explicit stack. Once you aim towards Algol and Lisp and start automating stack movements, the programs become coupled to that design and way of thinking.