Courage! You can do it! It would also be a great learning opportunity since you have the other 2 libs to use as an example. You should go for it and then put it up for code reviews before using it. Seriously! Give it a shot and then ask HN to review it in another Ask HN.
Hey Iris, if by chance you read this I just want you to know you should never be ashamed to be who you are, that there is hope in this life and that you are worthwhile. I am sorry things are so terrible and that you feel so bad. Thanks for being willing to be so open about it in public; honesty about the bad parts of our personal lives in public always takes courage. If you need somebody to talk to I am sure there are plenty of people here, but please feel to reach out to me,
"Back in the ‘60s and ‘70s, when microcomputers like the Apple II were all the rage, computer time was expensive, pressure-packed and cumbersome."
Does no one fact check anything anymore? If you're going to base part of your argument around technology that was around before you were born maybe do a little more research? And also... get off my lawn? Am I really that old?
At InterviewKickstart.com, we train candidates on various interviewing styles.
We believe, that a whiteboard is here to stay for some time, however much we hate it. Why?
1. Coding is perceived to be a commoditized skill, but engineering is not. Most companies worth their salt, hire engineers and not coders.
In today's world of nearly everything available readily, coding is maybe 30% of an engineer's job. Rest is designing, explaining and thinking in a collaborative setting to arrive at the right solution/design/spec. There is no better tool for collaborative working than a whiteboard, and you want to see those skills in an interview.
2. It's really easy to discuss a system-design question. Reading code samples and documents doesn't give you a good idea of how a system is designed, as much/fast as talking to the person does. When talking about such high-level concepts, a block-diagram on a whiteboard is inevitable.
3. Coding doesn't happen at speed of thought. Whiteboarding does. When you are trying to assess someone's thought-process, you need a tool that caters to that speed.
4. Whiteboards are way more "visible" and life-size. They force you to stand up and hence pay attention.
5. A more subtle and controversial reason: White-boarding allows for approximation in a solution, which can be a good thing for an interviewer. Most interviewers are only concerned with high-level aspect of code and don't want to take the time to read a solution in detail. Whiteboard provides that out.
6. When writing code in an assessment tool, it is not sufficient that the test-cases pass. You also have to pay attention to the time and space complexity. And when that complexity is not what you want, you feel like discussing it with the candidate, instead of just rejecting him/her. Whiteboarding allows the interviewer to pay attention to those things quickly.
7. Google does it! So everyone is going to keep following that :-)
Pair programming is a great alternative to whiteboarding. But still it doesn't replace a whiteboard, which is just so fast, collaborative and convenient.
More commonly linguists talk about Swadesh lists. For the most complete modern collection of Swadesh-like lists and a program/algorithm for automatically generating a language family tree from them see: http://asjp.clld.org
While ASJP is used to explore potential relationships, it should be noted that it cannot reliably determine language relatedness by itself. The gold standard for that is still the comparative method. 
I think this is the part where you're doing some magical thinking backed up by anecdotes. Have you done any actual experimental work on those who have failed the question but that you've hired anyways? Have you then been able to objectively measure how well they communicate? Your sample size seems pretty small (a couple hundred) so my guess would be no. I frequently see this kind of thinking about interview questions: "If somebody fails this problem this way, then they'll perform poorly on the job in the following way." Unless you actually have performed a study on this kind of thing, then you're probably just guessing when you say those kinds of things, and you're showing a lot of not particularly rigorous thinking about the relationship between the interviewing process and on the job performance.
It's definitely a small sample size, but I have more data on this than any other techniques I've seen out there.
I've been overruled once after no hiring a candidate. Low and behold the same person ended up nearly getting fired 9 months later for the very same issues that came up from this question. They struggled to answer even the simplest questions with one sentence responses.
So, that's a sample size of 1. Not quite what we would call scientifically rigorous ;). I'm not saying it's not a useful question. I'm just saying, you jump to a whole lot of conclusions that are clearly not based on evidence in your hiring process. That's fine, just be aware that your hiring process is not doing what you're thinking or asserting it's doing.