My idea is to add the keywords “send”, “to”, and “burn” so that they can be used as syntactic sugar for the sort-of cryptic address.call syntax.
Example:
send x to y;
burn z;
This would be equivalent:
y.call{value: x}("");
payable(address(0)).call{value: z}("");
The closest thing right now is in this OpenZeppelin utils code here. But including this utils code adds to the contract bytesize slightly, and the extra safety checks in there might be redundant and waste gas.
Also I’m looking for a job. I appreciate any help in that regard 
For burn there are multiple ways to achieve this and so I’m not so sure about enshrining one of them. You can send to 0, as you have here, or you can send to 0xdeadbeef... to make it clear this wasn’t an accident, or you can create a contract that self destructs to itself which will actually delete the ETH.
I don’t follow your reasoning. If the end state is the same (ether gone) then it doesn’t matter which dead address you send it to, so the burn keyword could compile to bytecode that sends it to the zero address. Also creating a contract is more expensive.
What do you think about the “send” syntax?
The end state is not the same. If you want to actually burn ETH, then you need to do the self destructing contract thing. If you want to be clear about intent but save money on gas costs, then sending to 0xdeadbeef makes it obvious the assets were burned on purpose rather than by accident. Sending to 0 is certainly the easiest solution, but much of the ETH sent to the 0 address is on accident, not intentional, which is why it makes it a poor burn address in many cases.
I’m fine with the send stuff you proposed, but others may care more than I do. I have been lobbying for Solidity to deprecate .transfer and .send basically forever but have struggled to gain traction on it. Perhaps getting a viable replacement is the first step to achieving that?
Oh okay, I didn’t know that. Then we would need to decide what bytecode the burn syntax would generate.
I discovered an EIP for pay and burn opcodes: EIP-5920: PAY opcode - Core EIPs - Fellowship of Ethereum Magicians
If this is approved then these would be the best fit for the send and burn keywords. We could have “pay” be the keyword instead of “send”, or something else.