In fact, it drove me to write my own editor recently (because, frankly, it felt more straight forward to write my own editor than to learn elisp well enough to do what I wanted with Emacs)
I currently get around window confusion by programming the F keys to certain windows. E.g. if I hit ctrl-shift-f1, my currently focused window will be bound to f1. If I hit f1, that window will be brought to the top. I did this with xbindkeys and xdotool.
So when I first start a session, I bind everything. F1 my IDE, F2 my command line, F3 my notes, F4 my browser.
The UI really has a lot going for it, though part of that is that we've spent our whole lives learning it. Plus many of the shortcomings of paper have been at least partially overcome by clever workarounds (like indexes).
I really need something that syncs across all devices, can take handwritten or keyboard input, is searchable, and organizable via some kind of embedded links to other content in the "notebook". Usually you can get like half of those things in one piece of software.
I was really hoping the Microsoft "Courier" tablet concept would become a reality, but nothing yet...
Maybe you could share your methods paper methods in a blog post or something; I'd be interested in reading it.
Especially with Org-Babel you can develop and document scripts at the same time. Give it a shot if you haven't before.
I think that's actually one of the biggest challenges in this space. E.g. there are a zillion different Todo apps or notetaking apps largely because there is an infinite set of possible ways of working with them and people develop very specific styles.
I think this is one of the reasons for the success of things like Trello: Trello is very generic and impose very few limits on what you can do with it. But even Trello won't conquer even the Todo/lists type niche entirely because it's not generic enough.
Same for things like OrgMode. It may get me 90% of the way there, but paper gets me 95% of the way there, because I'm effectively implementing my own workflow in my mind exactly how I happen to decide I want it right now.
And "right now" is a big part, because one of the things I've found both with plain text and with paper is that workflow at least for me does not remain static very long. My preferred format changes frequently depending on type of project or even specific tasks or just over time. Any "perfect" application to handle this would need to be able to accommodate that without making me conform to the tool.
Instead when I try tools for this, I often end up finding one I like, spending time on it, only to then start feeling constrained by it not because I've learned new limitations I wasn't aware of, but because the way I use the tool is slowly drifting towards a new workflow.
This might be a personal flaw, but from seeing people take notes, I think you'll often find that part of the flexibility of paper is exactly that your workflow can drift over time without making you hit a wall.
Meanwhile, it took me less than a day to have the basics in place (not entirely from scratch; I borrowed a very basic starting point [1]) in Ruby, and I've spent less than a week getting it to a point where I probably using it about 3/4 of the time (falling back to Emacs on occasion) (my own editor isn't pushed anywhere, but it will appear here [2]).
Of course it's not as feature-full and polished as Emacs, but it has most of the features I need, including sufficiently tolerable auto-indent and syntax highlighting (courtesy of "rouge", a Ruby highlighting library that can output ANSI codes), and with a bunch of custom transformation rules to e.g. add lots of extra stuff to my Markdown files to make my notes look nicer.
One thing I find is that with respect to things like this it's very much a 20% of the time to get 80% there thing, but if you write software mostly for your own use, getting 80% there is often sufficient. E.g. I haven't added a "safe" extension mechanism - my editor will crash if I decide to customize something, because the "extensions" are modifying the core of the editor rather than get treated as an embedded language.
That'd not really be acceptable as a general purpose editor. But as my editor for my personal use, it's quite ok (and loss of any substantial amount of data is easy enough to protect against). It's shortcuts like that which makes it viable. E.g. I also know that trying to open a gigantic file with it would be silly, but I very rarely do that, and can resort to a "grown up" editor when I need to.