If you have names with single quotes you can use this formula:
DLookUp("[Current Wage]","On-Call Wages","[Employee]='" & Replace([Forms]![On-Call Records]![Name],"'","''") & "'")
The the resulting where clause is 'O''Connor', which is the correct way to use a literal string containing a single quote inside of it.
Not sure if that would work if the name had two single quotes in a row, a single quote at the beginning, or a single quote at the end (i.e., ''OConnor, O''Connor, or OConnor'' are all possible failures). I don't think that's a problem.
Nearly all programming languages use a double or single quote to enclose literal strings, and for those that do they all require what is called an escape character to allow for a double or single quote to appear inside a string. So, this wasn't an oversight but simply a common limitation of manipulating raw strings in a programming language that uses a single quotes (or double quotes) to delimit strings. As you see from the previous post, it comes up in syntax for other uses as well, not only for raw strings.
For what it's worth, whenever possible database designers will use employee ID or employee number for lookups, rather than the actual employee name, to avoid problems exactly like this (as well as improve efficiency in large databases, and, most importantly, solve headaches when for example an employee's name changes after a major life event such as marriage or divorce).
Speaking of this, I recently read that Wozniak was employee number 1 at Apple and Job was employee number 2, which made Jobs upset since he wanted to be number one. So he took employee number 0 instead! But the payroll system required a positive integer for employee number, so it didn't really work after all.