I think Greenlinks is referring to the idea that if you can steal someone's session ID by exploiting the Heartbleed vulnerability, you can gain access to other people's accounts within IP.Board by hijacking their session, and is looking for mitigations for that.
I guess this is where session IP validation would come in, if you're particularly paranoid about man-in-the-middle attacks, but there's very little else IP.Board could do.
I think this is your key misunderstanding, which is logical, but still incorrect. Whilst it would certainly be possible to maintain near 100% backwards compatibility if IP.Board included a specific app-facing API, wrapped around the core logic that actually makes things happen, that is not the case.
In IP.Board (and all competing products,) any part of the software can be used as an API. Third party developers have the ability to extend and modify *any* class within the system, as well as hooking into specific points within templates and pre-defined data hooks. In theory, certain data hooks could be maintained as part of a rewrite, and there could be an intermediary layer allowing "old style" plugins to continue working where they only use those data hooks. However, by their very nature, plugins that hook into core classes within the platform couldn't possibly work if that class no longer exists. The same applies to hooking into templates, if that template (or the part of it you were relying on) is no longer there, how can it be hooked into?
It is very different developing a piece of forum software than it is developing firmware (or even, for example, a ReST API.) In the latter case you pre-define everything you want to expose, you know what you need to maintain and how to maintain it. It's just not possible to do that when you allow developers limitless access to the core of your application.
I agree on the front of using DATE/DATETIME columns in SQL, they're more commonly accepted as the standard for storing dates these days - There was a time when you'd be seen as a crazy person for doing so, but that time has passed. All of the major frameworks use DateTime in PHP and the appropriate DATE types in MySQL now.
ENUMs, however, I disagree with. They're fine if you're going to use MySQL strict mode, but in a situation where you can't control that (as IPS is,) I wouldn't go near them. In anything other than strict mode, MySQL will silently fail if you pass an invalid value for an ENUM column, storing a blank value in the database - they just can't be trusted.
The biggest improvement I could see for the IPS suite in terms of using the database is properly using foreign keys (incl. the ON UPDATE / DELETE functionality) and, where fitting, triggers. It can save an awful lot of code.
We have selected the list of features we're going to finish implementing in IP.Board 3.2, and we'll blog about them as and when they are ready to be announced, as we have done with the other features so far.
We always use the features from this forum when coming up with the feature list for new versions, so yes we will keep anything else in mind for the next release after 3.2. :)