how many more programming language could be attached to this - is there limit?
There is no limit. You can use as many programming languages in a single program as you want.
Using more than one language in the same project (but not necessarily the same program) at the same time is called Polyglot Programming.
There is even a programming paradigm called Language-Oriented Programming, where you not only use more than one language within the same program at the same time, but you actually create languages to fit your problem domain. Just like you create many many different highly specialized objects to solve a specific sub-problem in Object-Oriented Programming, you create many many different highly specialized programming languages to solve a specific sub-problem in LOP.
What are some other programming languages that have a similar feature?
It's not a feature of the programming language, as you have discovered yourself, it is a feature of the implementation. (Or, to be even more precise: a feature of the interactions between the implementations of all the languages involved.) In your case, it is not the Python programming language that allows this interoperability, it is the IronPython implementation – you couldn't interoperate between C♯ and Python nearly as easily if you were using CPython or Jython.
Note, however, that a programming language specification may of course demand that all implementations must be interoperable in a certain way.
In general, in order to mix two different programming languages, the programs in those languages must be able to exchange data with each other, as well as affect each other's behavior somehow (e.g. call functions). Let's call the thing that makes it possible for the languages to interoperate the "magic channel".
The more basic and low-level the magic channel is, the more likely it is that the two languages will be able interoperate in some way, but the flip-side is that the interoperation will be of much lower "fidelity". In the worst case, you create two completely separate programs, one program could simply write its output to a file, which is then read and parsed and processed by the other.
The more high-level the magic channel is, the higher-fidelity the interoperability will be. For example, a class in language A can inherit from a class in language B and call methods written in language C. But on the flip-side, the more high-level the magic channel is, the more likely it is that there will be an "impedance mismatch" between the magic channel and one of the languages. Imagine a magic channel which is based on objects, classes, and methods, and now you try to interoperate between Io (which has no classes) and Forth (which has no objects, not classes, and no methods).
Many programming language implementations allow basic interoperability with a subset of the capabilities of the C programming language as their "common magic channel". This is usually called a Foreign-Function Interface (FFI). Since many modern Operating Systems are based around the semantics of C, many programming language implementations are implemented in C or languages that can easily interoperate with it (C++, D, Rust, Go, etc.), a C-based FFI will usually allow interoperability with almost anything. But, it is somewhat low-level.
Programming language implementations that target the Java platform or the CLI platform, usually try to use that platform's native abstractions as their magic channel, which are a bit higher-level than C (e.g. both Java and the CLI have objects, classes, and methods).
Microsoft created the (now mostly abandoned) Dynamic Language Runtime as a way of achieving interoperability at an even higher level. As a little bit of history: IronPython was written by the author of Jython to prove that the CLI was not usable for dynamic languages. Much to his surprise, his early, un-optimized throwaway demo turned out to be not only much faster than he thought but also much faster then Jython, and even faster than CPython. He was later hired by Microsoft, and another person was hired to write an IronRuby implementation. They analyzed the implementation of IronPython and potential requirements of a Ruby implementation (as well as existing Ruby implementations for the CLI such as Ruby.NET), while also keeping an eye on other potential languages like ECMAScript. Then, they extracted parts of IronPython and made them generally re-usable, refactoring IronPython to be built on-top of this newly created so-called Dynamic Language Runtime, at the same time building IronRuby as open-source and the never released proprietary ManagedJS (an implementation of ECMAScript) and Dynamic VB (aka VBx, an implementation of a language that can be viewed as either a modernized continuation of Classic VB6 or a dynamic variant of VisualBasic.NET). Other developers quickly picked up on the DLR, producing e.g. IronJS and IronScheme.
MS demonstrated impressive interoperability between those four languages as well as with other "classic" CLI languages such as C♯ and F♯. Unfortunately, Microsoft completely abandoned ManagedJS and VBx, released IronPython and IronRuby to the community (with IronPython being picked up and IronRuby more or less dead) and also stopped development of the DLR. Now, only the minimal set of features of the DLR required to support C♯
dynamic are still part of .NET, the more full-featured version is maintained as part of IronPython.
In the Java community, there were and are similar projects: dynalang is now mostly dead, but dynalink, which was extracted from Nashorn in a similar vein as the DLR was extracted from IronPython, is alive and well, and is part of Java since Java 9.
A very interesting project is Truffle, which is a framework for easily writing interpreters for programming languages. In general, if those language interpreters are written according to certain interfaces and rules, they will be able to interoperate with each other and with other JVM-based languages (including, but not limited to Java) at a very high level. Truffle currently ships with implementations of Ruby, ECMAScript (including a Node.js compatible library and runtime), R, Python, and very interestingly, LLVM bitcode. Especially when running Truffle on the GraalVM, you get very good support for Polyglot programming.
The Parrot VM was a very ambitious VM and runtime that aimed to be a universal platform for dynamic languages. It was designed by the Perl6 community and intended as the primary target platform for Rakudo. At one time, it had implementations for Perl5, Perl6, Ruby, Python, ECMAScript, Lua, PHP, Scheme, and many others, but none of those were in a production-ready state.