What are the potential issues after data or log disk failure?
what are the possible SQL failure modes this could present?  Does the transaction log / SQL server architecture account for this type of whole disk failure?


SQL Server uses a write-ahead log (WAL), so any completed transactions should have at least been flushed to disk (unless you are using delayed durability).  This means that when your database comes back online, all committed transactions will be replayed from the log file.  In-progress transactions will be rolled back as well.


  Is it possible to have data loss in this situation (without considering corruption of the disk itself)


Despite the WAL architecture, I'm sure Windows didn't appreciate the abrupt disk loss.  It certainly seems possible that data could have been corrupted - for instance, if a single 8 KB page was halfway done being flushed to the physical log file, and the disk was removed at that instant, it seems like the log would be corrupted.

If you're using the Full recovery model, you could likely still do a point in time recovery up to right before the corruption.  But there would be some data loss due to the partial write.


  And what checks should/can be performed after such an event?


There's really not much to be done other than running DBCC CHECKDB.  This will check the database to see if it was corrupted during this unusual event.

Another option would be to restore a backup (from before this event) to a separate database / server, and then use a comparison tool (like SQL Data Compare from Red Gate) to see if there is any data that's different between the backup and the current database.