Would it be possible to add an RPC call to be able to determine if a node is fully synced? After reading this answer, where Peter Wuille talks about how a node can't really tell if it is synced or not, it got me wondering if there is a way we can tell that a node is as synced as it possibly can be given the peers it is connected to. 

Could we add an RPC call like getsyncstatus that would have the node ask its peers for their highest known blocks and if a majority (or some percentage) of their peers all agree on the best known block height, then it could use that info to be able to say (with not perfect reliability) how synced the node is?

So, for example, if a node has 8 peers, and 7 of them are returning 330448 as the best block height, and the client has information about block 330448, then it could give a status code and message signalling that it is up to date. If the peers give different answers (which could happen if you connect to a malicious node that is falsely reporting it's best known height OR if other peers are not fully synced), then it could give a status code and a message indicating that the search was inconclusive and they should try again later. And lastly, if 87.5% of nodes are saying 330448 and the node is only synced up to block 1000, then it can give a status code and message indicating that the node is likely not sufficiently synchronized. 

I think this would mainly be useful as a way to determine whether servers are sufficiently synchronized with the network for use on some application. The responses to this question describes a way to see if nodes are up to date, but they all seem kind of hacky, and I'm not sure they would be reliable enough.
Existing Methods
The Bitcoin client does have a way of detecting if it is not sufficiently synchronized. However, to my knowledge, it's not really exposed to RPC in a nice way.
It's called IsInitialBlockDownload(), and it will consider itself not synchronized if any of the following are true:

The client is importing from bootstrap.dat or reindexing the blocks it has.
The client has not reached all of its block checkpoints.
The client has received and verified a block in the last 10 seconds AND that block has a timestamp of more than 24 hours ago.

You can call getblocktemplate, and if IsInitialBlockDownload() is true, it will come back with an error of RPC_CLIENT_IN_INITIAL_DOWNLOAD (or -10).
Drawbacks

If your Bitcoin node is down for less than 24 hours, this won't detect anything wrong when it comes back up.
It's a bit ugly.
When your client gets within 24 hours of the current block, it'll think it's up to date, when it probably needs to get ~144 blocks.
If your client stops downloading blocks while it's still synchronizing, this won't detect anything wrong.

New RPC call
Let's suppose that we're designing a new RPC call from scratch. As other posters have noted, it's not possible to determine this perfectly in the presence of malicious actors. What factors could we measure to make an educated guess?

Node uptime. Has the node been up for at least five minutes?
Node downtime. Has the node been down recently? If so, take the amount of time that it was down, and divide it a thousand. If your node has not been up at least that long, then it is not synchronized.
Block timestamp. The network is fairly liberal about enforcing this rule, but my unscientific guess is that it's usually within half an hour or so. You could use this information in a similar way to how IsInitialBlockDownload() does.
Block height of central node. This is the &quot;Look at blockheight of blockexplorer,&quot; solution mentioned in the other question.
Your method would probably work. The only issue I can think of is that if you connected to another node that was still syncronizing, you'd fail to fail.