What CVE identifier will follow after CVE-2012-9999?
The Common Vulnerability and Exposures system is maintained by Mitre. The Mitre corporation manages the CVE list and serves as an organizer for the CVE community.
At the start of the year Mitre will allocate blocks of CVE numbers to various CVE Numbering authorities out of the full 9998 available (0001-9999). As a result, all CVE numbers issued to an authority within a given year will fall within a range. For example in 2012 all CVE numbers issued to Apple products fall within the CVE-2012-3600 range. Mitre will leave unallocated space in order to issue new CVE numbers if a CVE authority were to exhaust their supply.
So what about your question? What if they have 10,000 CVE numbers issued in one year? Well the most ever issued was 6,608 in 2006. So that was close, but since 2006 there has been an unsettling rate of decline so it doesn't look like we will ever issue 10,000 CVE numbers in one year. If we were, I suspect that we will have CVE-2012-10000. They would do this because its regular, the only reason why they have the four digit number scheme is to allow for pre-allocation to CVE authorities.
From my experience emailing Mitre is usually the best way to obtain CVE numbers. They treat you with respect and have the option to preserve your anonymity. Mitre will work with vendors to make sure the issues are fixed and issue a CVE to the public when a fix is available.
There was no need for anything beyond CVE-2012-9999 to be issued, as the last CVE ID issued for 2012 was CVE-2012-6700.
Since then, MITRE has determined that a situation such as you propose would be handled simply by adding digits to the end of the ID when needed. See my answer on the linked duplicate for more details.
So as of now we have larger CVEs (the DWF project https://distributedweaknessfiling.org/ has been assigned CVE-YEAR-1000000 through CVE-YEAR-1999999). I just assigned CVE-2016-1000000 to an issue found by Tenable (Ipswitch WhatsUp Gold 16.4.1 WrFreeFormText.asp sUniqueID Parameter Blind SQL Injection). So if you have not implemented https://cve.mitre.org/cve/identifiers/syntaxchange.html you're in for a bad time.