Our compatibility with Ethereum smart contracts is at the virtual machine level, so it doesn't matter what language (Serpent, Solidity, LLL, etc.), you write the contracts in---they'll run on both Counterparty and Ethereum the same. Between the Counterparty and the Ethereum communities, we'll figure out what languages we want to write contracts in and develop those.
Seriously writing HLLs for an entire new VM is something that takes years (so it is not surprising at all to me that Serpent is failing) so I very much doubt you can just create a new HLL and keep going (but please feel free to prove me wrong).
I have actually worked on such a project (around the time that Java was being designed and built) - so maybe you might want to consider looking at what we have done with AT (our approach will allow C/C++ to be implemented as the smart contract language in only a couple of months - we just need to find one LLVM expert and we already have the funds to pay that person).
Understand that I actually was privy to the Ethereum white paper before it was publicly available and had stated my concerns back then that the design was *wrong* (but hey I'm only a guy with more than 25 years software engineering experience - not a "wonder boy" with my own online magazine).