If the encryption system is any good, even noticing that two messages encrypted with distinct keys are, in fact, identical, would be considered a "break". An encryption algorithm has a "security level" expressed in bits; when the security level is k, then this means that the computational effort to enact a "break" should be on the amount of 2k-1 invocation of the underlying encryption function (to be precise, the success probability should be e*2-k where e is the effort, so e = 2k-1 implies a 50% success probability for the attacker).
For instance, if using AES with a 128-bit key, then you are supposed to achieve a "128-bit" security level. This means that if the attacker is ready to invest enough CPU power to compute, say, 270 invocations of AES, then he has probability about 2-58, aka "1 in 288230376151711744", to succeed. 270 AES invocations is a substantial effort; a good multi-core CPU can produce about 230 AES invocations per second, so we are talking about ten thousand big PC running for... three years. And this achieves a success rate considerably lower than winning millions of dollars at the lottery.
What counts as a break is anything which makes the system depart from its theoretical model, i.e. a pseudorandom permutation: using the encryption with a given key is akin to selecting a permutation on the space of messages, and a new key should mean a new random selection, independently of the previous. Noticing that two encrypted messages, with two distinct keys, proceed from the same plaintext message, would be a break, and the best attack method ought to be the generic one, i.e. trying all possible keys until a match is found. This method yields the probabilities explained above, i.e. "does not realistically work".
Right now, no such breaking method is known for AES.
Beware of outdated thinking. You appear to use notions of "correlation" and "unknown method" which were adequate about fifty years ago, but cryptographic research has gone a bit forward since that time. In particular:
We are now very strict about acceptable information leaks (your "correlations"), namely we accept none. And yet we have candidate algorithms (e.g. AES) which seem to achieve this high level of quality.
Encryption methods have been split into an algorithm and a key. The "algorithm" is what becomes code. The algorithm is supposed to be public, because all the secrecy is concentrated in the key; at least, there should be no harm into publishing the algorithm, if it is any good, and it would be very hard to prevent such publication anyway. See this answer for details.
Of course, if the algorithm was used sloppily, then anything goes. A core algorithm like AES is only an elementary brick; it processes 16-byte blocks. To encrypt a message (a possibly long sequence of bytes), you have to use the block cipher with a mode of operation, which is a matter of subtlety and can be done poorly -- sufficiently poorly to imply a total security loss.
There can also be side-channel attacks exploiting the information leaks through the behaviour of the encryption implementation, e.g. through timing. For instance, many AES implementations use in-memory tables, which implies data-dependent and key-dependent memory accesses, thus cache behaviour; in lab conditions, this has sometimes been exploited to extract the key. This is not an attack against the algorithm but against its implementation. Bottom-line is that implementation of cryptographic algorithms is a tricky task.
All of the above is about symmetric encryption, but the same kind of reasoning can be applied to asymmetric encryption, e.g. with RSA. A 2048-bit RSA key, properly generated and used, ought to offer a security level of about 112 bits, which is more than enough.
