The only real issue is when one node dies and its SQL instance(s)
failover to the other node so a single node has multiple instances
running on it.  You just need to make sure each node has enough
resources (CPU and memory primarily and to a lesser extent NIC
throughput and SCSI controller (or SAN HBA) capacity) to support both
instances simultaneously.

It also depends on whether it's acceptable to your business to run both
SQL instances at a degraded performance level until you can get the dead
node back on its feet (assuming the business doesn't want to fork out
the cash to have more CPU & memory in each node in order to adequately
run both instances on one node).

Personally, where I work we run 4 production clusters (each with 2 SQL
instances on it) and an off-site DR cluster (with 2 SQL instances on
it).  I can't remember a problem in the last 5 years that we've had on
any instance on our clusters that wouldn't have also happened if we'd
only had a single instance on each cluster (the issue were all OS level
or hardware level issues - to be honest, our stand-alone SQL boxes were
always more stable but obviously didn't have the failover capacity if
something went wrong).  However, we tend to run cluster nodes with a
little resource overhead in them in case of a failover.

--
*mike hodgson*
http://sqlnerd.blogspot.com