Get a degree in computer science. Go at night and on weekends if you must.
I agree with you that I think the academic approach wouldn't be as efficient as taking a more practical approach to what I need to know.
There's all the other stuff that you need to know, like the basic data structures, but these are (IME) hard to avoid if you've done much programming at all. I'm not sure you need to know hardly anything about hardware architecture unless you're aiming to code at a very low level, device drivers etc. Obviously, familiarity with machine code, cache characteristics, optimization at the assembly level, etc. are useful, but these things are best learned by sitting at a computer with a stack the Intel processor PDFs, an assembly timing loop and a simple algorithm you're trying to reduce the clock count on.
I'll add some of my own experience, as I got into compilers and currently work as a compiler developer. I was interested in compilers at a young age, I recall thinking hard in school about how one should go about evaluating arithmetic expressions correctly accounting for precedence. I wrote an open-source expression evaluator for the Delphi community, as part of the JEDI library. I built a regular expression compiler in Java, compiling to Java bytecode, as my final year project in college. Then, in my first job (in a software company, working on a green-field project, very lucky), I was able to point out the benefit of writing a custom compiler for a DSL to fill in a configurability-shaped hole in the architecture. After having built up this experience, I was in good shape when Borland (as it was at the time) came calling looking for an engineer for the Delphi compiler.
I don't think there's a deterministic kind of guarantee that can be drawn from this experience. But learning the whole stack of technology that you need to implement a language certainly gives you plenty of practice in a lot of the fundamentals of CS, right from data structures and parsing at the top (I personally would avoid parser generators as a didactic exercise) to machine architecture and cache hierarchies at the bottom, to details you'd rather not have to know about, like the idiosyncratic addressing modes of the x86 processor. And putting it into practice, even if it's in an open-source side-project, gives you a better angle on related opportunities.
Any chance you could give a list of that surprisingly smalll amount of practically useful stuff?
For data structures, it's more important to have a taxonomy, and a rough general knowledge of the kinds of data structures that are available, so that you know what's required and when, and have enough confidence to implement any given data structure as needed.
It's also nice to have the time and opportunity to look at different levels of various stacks, such as the network stack (the analog wire signals, how binary signals can be encoded on them, ethernet, IP, TCP and UDP etc.); and things like OS caching, process scheduling, etc. But where you're looking to put those kinds of things into practice, it's not difficult to take a day or two out of your time and read up on them - it doesn't take long to scratch deeper than an undergraduate course covers (IMO).
Depending on what area you target, other things can also be useful. Re compilers and languages, I'd be wary of taking the academic stance too seriously. Classic texts like the Dragon book overemphasize the analysis of finite state machines and pushdown automata, DFAs and NFAs, and the details of grammars and parsing, LL vs LALR, and generally all the data you need if you want to rewrite lex or yacc. But really, parsing is a very small part of writing a compiler and is actually quite easy, unless you're trying to parse C++ or something. And a more modern trend is to overemphasize type systems and their analogies to proof systems; I'd also steer fairly clear of these guys, as they are (IMO) primarily interested in churning out PhDs by creating new mathematical abstractions that have very little practical application.
When downplaying the practical value of much of a CS degree, however, I'm assuming that you already have pretty decent coding chops. For example, I would expect that you wouldn't be intimidated by programming competition problems, for example see some of the problems in the PDFs from this page:
http://acmicpc-live-archive.uva.es/nuevoportal/
The harder problems rely on a relatively small amount of base knowledge, but you have to be pretty comfortable with recursion, generating combinations and permutations, dynamic programming, and often a little computational geometry. The easy ones are more like warmup in how to read and follow instructions.
Another consideration is whether you ever want to work in the US. Getting a H-1B isn't easy without a degree.
It's worth asking for a meeting or lunch the supervisor, and explaining the worries about where you can go with this firm and why that lack of hardcore software prospects is worrying you a bit. It sounds very much as if you've ended up working as a mechanic when what you really wanted to do was design engines or gearboxes. If your employers aren't jerks and you've been doing a good job up to now, they may well offer some career-building assistance or advice that you might not have thought of yourself. Tread carefully, to ensure you aren't the obvious choice if the economy requires them to lay off a few people in every department ('Oh, let's get rid of yacoder, he's not that happy here anyway so he won't make a fuss'), but keep an open mind. For all you know the lack of core software openings at your company is due to management's inability to build a better programming team, and they might see your ambition to delve deeper as a valuable future asset.