Additionally, it should be noted that mainframe IBM COBOL has also continued to be updated and extended, to the extent that it has native support for JSON serialization/deserialization for building web services.
There is an enormous amount of new COBOL being written even for mainframes.
There is almost certainly a large market for COBOL on .NET if it managed to replicate some of the functionality IBM added on top of the standard.
A better term for COBOL (and mainframes for that matter) would be niche, not legacy. It's the best language for a very particular subset of business problems, and there hasn't really been much attempt to replicate that functionality by newer languages, and so COBOL remains in use. There simply is not much overlap between the folks coming out of school interested in language design/theory and those that are aware of COBOLs continued dominance in certain types of business.
It's also ruthlessly efficient compared to something like Java or .NET, and even beats out C by a wide margin in certain scenarios. That isn't as important if your not laying mainframe licensing fees, but it is a common headache that makes migration to some of the current virtualization based modernization platforms a headache.
Eh. I worked on IBM's COBOL compiler for four years or so, and I think you're overselling COBOL. COBOL is the best language for extending the functionality of critical legacy systems already written in COBOL. I have a soft spot for the language, in the same way you might for a puppy that is big-hearted but ultimately not very bright, but I can't imagine a greenfield project where COBOL is the right implementation choice. (Idiomatic COBOL does end up being surprisingly fast, mostly because the idioms were established in the 60s where things like "dynamic memory allocation" and "a call stack" were too expensive.)
The market for COBOL on .NET is limited by the fact that existing COBOL code is usually tightly integrated with the rest of the mainframe ecosystem (CICS, etc). The average COBOL shop has a low appetite for significant change. Even just recompiling the codebase with a newer version of the IBM compiler was often a big lift. (IIRC, when I left, COBOL 6.1 was generating code that was nearly twice as fast as COBOL 4.2 for CPU-bound code, although admittedly a lot of real-world COBOL isn't CPU-bound. It was still difficult to get people to migrate.) Anybody who wasn't change-averse and tied to the mainframe probably stopped being a COBOL shop years ago.
Edit to add: None of this is to say that Otterkit isn't a cool project! I just don't expect it to sweep through the world of banking.
There is an enormous amount of new COBOL being written even for mainframes.
There is almost certainly a large market for COBOL on .NET if it managed to replicate some of the functionality IBM added on top of the standard.
A better term for COBOL (and mainframes for that matter) would be niche, not legacy. It's the best language for a very particular subset of business problems, and there hasn't really been much attempt to replicate that functionality by newer languages, and so COBOL remains in use. There simply is not much overlap between the folks coming out of school interested in language design/theory and those that are aware of COBOLs continued dominance in certain types of business.
It's also ruthlessly efficient compared to something like Java or .NET, and even beats out C by a wide margin in certain scenarios. That isn't as important if your not laying mainframe licensing fees, but it is a common headache that makes migration to some of the current virtualization based modernization platforms a headache.