I find your suggestion problematic, because

• If user tries to read from encrypted table, what should be returned to user, ER_CRASHED_ON_USAGE ?
• How constraints are enforced ? Consider a case where we have two tables, one encrypted and one not encrypted and foreign key constraint between them. Thus, you can read unencrypted table, but not modify it (because we can't enforce constraints to encrypted table). Again, what should be returned to user, ER_READ_ONLY_MODE ?
• We find on buffer pool code that page is corrupted, how to identify that it is encrypted or it is really corrupted, from original page read from disk we could find out (page type, key_version) is it encrypted BUT if page is really corrupted on disk it could also corrupt exactly these bytes also ?
• Ignoring the page corruption on buffer pool code is easy, but I need to research how "easy" is to skip a lot of page contents validations after that.

Before I close issue by Won't fix, I will do some code reading also.

• If user tries to read from encrypted table, what should be returned to user, ER_CRASHED_ON_USAGE ?
• How constraints are enforced ? Consider a case where we have two tables, one encrypted and one not encrypted and foreign key constraint between them. Thus, you can read unencrypted table, but not modify it (because we can't enforce constraints to encrypted table). Again, what should be returned to user, ER_READ_ONLY_MODE ?

From users' point of view, I don't see how any of this is a problem.
InnoDB already detects when a table cannot be read because of encryption, it does so on startup and returns the proper error message as quoted in the description. That's exactly what should be returned when the table cannot be used at runtime, either directly or via constraints (iirc there is some generic message that an error comes from a storage engine, and specifics get listed in warnings). It is still better than making the whole instance unavailable. Imagine that somebody was careless enough to experiment with some bad encryption plugin, created an encrypted table and then the plugin broke, could not work, could not decrypt, whatever. Does the user have to throw away the whole instance because of that?

• We find on buffer pool code that page is corrupted, how to identify that it is encrypted or it is really corrupted, from original page read from disk we could find out (page type, key_version) is it encrypted BUT if page is really corrupted on disk it could also corrupt exactly these bytes also ?
• Ignoring the page corruption on buffer pool code is easy, but I need to research how "easy" is to skip a lot of page contents validations after that.

I obviously cannot answer that. In fact, I know so little about internals of InnoDB that I can't even tell why such a page (which was encrypted earlier, but cannot be decrypted on server startup) has to be in a buffer pool at the first place. I'd think – it couldn't read the tablespace, complained and forgot about it till the next time. But apparently it is not so; anyway, I surely hope that InnoDB can tell an encrypted page from a corrupted page.

Before I close issue by Won't fix, I will do some code reading also.

It cannot be "Won't fix". At the very least, it should be not an assertion failure but an error message, followed by "InnoDB init returned error", and shutdown if InnoDB was a default engine or continuing without it if it was not.
But I still hope you'll find a better way than just failing the whole engine because of an unreadable user table.

http://lists.askmonty.org/pipermail/commits/2015-August/008263.html

Contains change on handler API.

Actual review later in MDEV-8764.