"But we've debated the point ad nauseum about how your resume needs all of the right buzzwords and TLAs to get past the HR drones or the resume-scanning software."

Yeah - so put them all on your resume - like in skills section. That matches the scanners. Really.

Skills: Java, C/C++, Fortran 77, Hypercard, Space Lauch Systems Engineering, Ear Wiggling, Nose Twitching....

Notice I don't say where I learned them here. But this resume will make the first cut.

"First and foremost is showing that you've learned AND USED what the future employer wants on the job at your current employer."

No, thats the second cut on the resume thing. Its where they dig through your experience listings of job descriptions to try to determine the actual depth of the skills you mentioned. I often run across candidates that list a skill and don't show where they used it on the resume - so I end up dragging that out of them at the interview. Thats cool - note that they GOT THE INTERVIEW. Often its just an omission or they have minor experience with something that didn't rate exposition in detail.

"Today's economy doesn't allow a potential employer to take a chance on you just because you've learned something on your own and need the opportunity to show him/her that you actually know it."

True enough - and yet - the average interviewer will just ask you a few questions about the technology to try to draw out whether you're BS-ing them or not. If you say XWindows programming with C++, I'll likely ask you how action callbacks on buttons were implemented. You'd need to know the toolkit well enough to have completed a tutorial at least to answer that question. If you do - I'm satisfied you know what we're talking about.

The other trick is to get OJT thats not strictly sanctioned. When Java first came out, I was working on a C++ program that needed to send commands to a 5ESS telephone switch. Only the switch was down most of the time. To facilitate testing the program I needed something that would at least accept network connections and echo the commands to somwhere while issuing expected responses. For the heck of it my dev partner wrote it in Java - he fixed it so each session ran in its own thread. Did it need to be Java? No. He just wanted to get some experience with it so he could be knowledgeable about Java threading and sockets. No part of our job called for the use of Java.

I did the same thing when I was an engineering programmer for the Department of Energy. All development was in Fortran (powerflow simulation programs). But we had lots of tools and I had one tool that needed to extract reports from the simulation logs. Problem was, the logs could be arbitrarily sized and Fortran doesn't have dynamic memory allocation - so I asked if I could write it in C since it has malloc. They said sure - and I taught myself C at the expense of the DOE (and switched jobs right after).

Point is, you probably need tools from time to time. So write them in something you want to learn.