So the case you are talking about is:
SELECT * FROM tbl WHERE indexstringcol = 99
You are correct that the index will not be used in this case. Or more precisely, it cannot be used as intended with an Index Seek. An Index Scan is still possible.
On the other hand, if you have the query
SELECT * FROM tbl WHERE indexedintcol = '999'
In this case, the index can still be seeked.
The reason for this is is that when two data types meet, SQL Server applies a strict data-type precedence, and the data type with lower precedence will converted to the type with higher precedence. Numeric data types has higher precedence than strings.
This means that in the second example, the string literal is converted to integer, and the columns is unaffected.
In the first example, the string column is converted. The index is organised for string values, so that '100' comes before '99', but since that is not true for numbers, the index is not useful.
If there are other such cases? Yes, the general rule is that when an indexed column is implicitly converted, this prevents an efficient use of the index with an Index Seek.
There are some exceptions, though. For instance, this still uses the index in the best way:
SELECT * FROM tbl WHERE indexeddatecol = @datetimeval
This is because they have a special rule for this in the optimizer.