Speaking for myself on the specific points you've raised: We're a django shop, but being a rails dev doesn't rule anyone out. A demonstrated record of shipping product and solving hard problems, regardless of language, is generally better than a lot of buzzwords that happen to be on point with the tech I'm working with to day. That candidate will probably get a phone screen, at least. A list of job responsibilities or technologies on a resume won't get you an interview if that tech isn't a good match for what I care about today.
But that's rails... ruby is a pretty strong language, and it's a much closer map to python than other options. As for your other languages...
Someone who's spent their life in PHP with no experience outside that language? At this point, I'd probably pass on that resume. The problems I deal with require a breadth of experience in deeper software engineering-y topics: networking, storage, maintainability... my assumption would be that you haven't been given hard enough problems that require you to get outside of the PHP box, if that's all you've ever done.
Similarly Java vs. Scala. I see a lots of J2EE resumes, and my experience with interviewing those folks is they may understand the J2EE/Hibernate/SOA/webapp stack, but when it comes to non-webapp problems, they're lost. I'd be more likely to talk to someone who has Java, C and Python experience, but no Scala, than someone who's got a broad Java base but has never branched out of that particular language. Scala experience, whether or not immediately relevant, is more likely to be correlated to be harder problems, self-development and exploration -- at the very least, that someone is trying to keep up with industry trends.
Maybe my J2EE and PHP judgments aren't fair; but they're heuristics developed over some time.
It seems like the requirements for jobs continue to increase. Not too long ago, you could get a job just having experience in one/a few language(s) with a few things in a portfolio.
As a guy who's always looking for advice on getting an entry-level position, I've been told to learn a dozen or so technologies before applying for a junior position: HTML, CSS, JS, Python/Django||Ruby/Rails||PHP, Linux, Data Structures and Algorithms, Photoshop, Design Principles. I also need to have some good quality projects and approach hard problems, which can be time-consuming and difficult on your own. Even then, some places filter out candidates who don't have a CompSci degree.
To me, this seems a little high for a junior position (Any company, not Google) and sounds more like a full-stack web developer (I'm just shooting for a Front End spot). With no professional experience, there's no way I'm going to be proficient in all of those domains unless I spend a long time learning on my own and that doesn't exactly pay the bills.
As the problems get harder and more people drift towards CompSci, the requirements for even a minimum-level position will continue to increase, while the time to learn all of the requirements remains the same. This will hurt the talent pool in the long run, although people that have been riding the wave will command very large salaries if the talent gap continues to widen.
The problem is that even at the junior dev level, you're delivering solutions, not skills. And you really do need all those skills to build a useful frontend webapp. The only two that you could possibly cut out are Data Structures and Algorithms & Photoshop, and both of those definitely help.
The way I would approach it if I were gunning for an entry-level frontend dev position would be to just start building webpages. Start with HTML, and layer on CSS. Make it interactive with Javascript. Now serve it up from the backend with Django/RoR/PHP, which will also teach you Linux. Work with it for a while and you'll see the reason to learn Design Principles. You don't have to learn everything about those topics at once, but as you face new problems with your webapp, you layer on new skills.
Having some experience in one of those frameworks is certainly useful but it's not really a requirement of being a front-end dev.
As long as you're intelligent and can use Google you'll pickup working knowledge of a language or framework quickly. This is why the best companies hire people based on who are they are, not what they know.
There is also the semantic issue of how deep one must understand a language or framework. For example; I build custom WordPress themes and have a general knowledge of PHP but I'd never put on my resume that I know PHP. Not because I don't want to work with it, but because working knowledge doesn't constitute extensive knowledge.
A junior level position for a skilled worker usually requires at least an undergraduate degree, which is four years of training. If you aren't getting a CS degree, you're still perfectly eligible to get a position, but that doesn't mean you get to skip the training. The tech you need to learn for a junior position can easily be learned in an equivalent four years, and if you're committed you can probably learn it in a year or less. That's a hell of a lot better than the situation for other skilled workers.
If you want real advice for getting an entry-level position, it's actually quite simple. Step one: build things. This will help you develop the necessary skills to contribute to a team. Step two: tell people about them. The majority of job openings are filled through referrals and networking; sending in resumes to job postings online is a very inefficient use of your time.
Go based on the job description and if you find a company you want to work for, figure out what technologies they use internally via open source or LinkedIn profile skill sets and job ads. Write on your resume specifically what the job ad asks for, practically repeating what it said, and mean every keyword. If you don't have the skills listed, don't apply for that specific position. Full stack or not, if you want front-end, learn front-end technologies. Starts with the browser, might end at the backend, but honestly? People will love you if you simply don't mess up existing code and can learn on the job from more experienced devs. I don't think that will ever change, it's just getting your foot in the door that's more interesting. As much as possible, try to gain the interest of your prospective manager and ... sometimes it just takes luck for both you and your prospective employer to agree you're a good fit long enough to sign the paperwork and deliver during the first few months. It's okay if the job's not what you expected, as that's happened to me for pretty much every job I've had. Thankfully, for most employers, "just doing your best," is enough. Mostly.
This idea is missed by a lot of candidates "Write on your resume specifically what the job ad asks". When I am navigating the online job posting jungle there is one thing I try to remember, you are being judged by the paper you present. Your goal is moving to the next step (interview)so you can dazzle them with your skills/personality. Spending some time learning about the tech the company uses, and from the JD, how they use that tech instead of rushing as quickly as one can to the submit button can make a huge difference. Give some consideration to who is on the other side of that submit button. In most cases the person reviewing your resume is not technical and could really use your help discovering why you are a fit for the job. At some point the non-A playing Ninja Rock Starey regular folks (myself included) are playing a numbers game and tailoring your resume to speak to the specific position/company can help shorten the odds. That being said, networking is by far the best way to find a gig but can take time, and always works best when you have a job.
They're both generally used to solve one problem and, while they both may be really great at it, don't have a lot of applicability to other things. It isn't a bad filter - don't bother with someone who only has experience and interest in one of the tech stacks that's a total institution.
But that's rails... ruby is a pretty strong language, and it's a much closer map to python than other options. As for your other languages...
Someone who's spent their life in PHP with no experience outside that language? At this point, I'd probably pass on that resume. The problems I deal with require a breadth of experience in deeper software engineering-y topics: networking, storage, maintainability... my assumption would be that you haven't been given hard enough problems that require you to get outside of the PHP box, if that's all you've ever done.
Similarly Java vs. Scala. I see a lots of J2EE resumes, and my experience with interviewing those folks is they may understand the J2EE/Hibernate/SOA/webapp stack, but when it comes to non-webapp problems, they're lost. I'd be more likely to talk to someone who has Java, C and Python experience, but no Scala, than someone who's got a broad Java base but has never branched out of that particular language. Scala experience, whether or not immediately relevant, is more likely to be correlated to be harder problems, self-development and exploration -- at the very least, that someone is trying to keep up with industry trends.
Maybe my J2EE and PHP judgments aren't fair; but they're heuristics developed over some time.