Ok, this might become somewhat technical but maybe someone is interested to look behind the scene.

First of all a lot of "we are developing" should be read as super early design and/or proof of concept stage :o)

HMT:

The HMT has three parts:
First is the setup part, where the creator of HMT needs to set up its NAI, inflation rate, initial distribution parameters etc. When doing changes in hived I've not run into code that would handle that, at least nothing particular comes to mind at the moment, so if that part is even implemented I can't say anything about it.
The second part is the life and storage part. Objects that are to hold HMT balance, handling of transfers, rewards for posts, vesting etc. - that part is in pretty good shape, there are also unit tests for it. When we were making changes in hived for HF24, that code was also updated (and fixed in couple of places) so it not only still compiles but also works not worse than before the changes.
The third part is what it can be. That's my personal view of the potential of HMTs. Since there is vesting and distribution through post rewards, it could also mean there could be governance. Not the witnesses because those wouldn't be producing blocks, but something similar. Let's call it council. The council would be selected very much like witnesses, but solely with particular HMTs. Now having that there are two ways of using it. First: decentralization of communities - a community bound to HMT could be governed by a council selected by users, not by dictatorial rule of the owner and his chosen admins and moderators. Second way of using HMT governance would be to bind HMT with 2nd layer app and let the council define DAPP related custom json operations, things like

"operation X consists of the following mandatory fields:
actor = existing account whose posting authority is required,
amount = positive value expressed in HBD,
identifier = 32 char alnum string"

Those simple checks would be made by 1st layer (today custom_jsons only validate if they meet authority requested by the very same operation, which means all the checks are pushed to the DAPP, which in turn leads to bugs like: "A follows B" can be pushed by account C as long as the custom_json declares it needs authority of C, unrelated to A - actual bug that existed in Hivemind). With the custom operations defined and validated in 1st layer the DAPP can be sure that at least the very basic checks are already done lessening the burden of the DAPP developers (and not including custom operations that don't meet those basic rules into blockchain - this is especially important if you want to make changes to such operations and force outdated DAPP instances to update). Of course it does not mean that all such validated operations will be valid, f.e. the identifier from above example can mean some object in DAPP state, that has to be validated using that state - unknown to 1st layer. I'll get to that point later in "pitfall of state as hash".

Vote expiration:

I was initially for EOS style vote decay, but maybe clear cut expiration won't be so bad as long as we properly implement the starting point. I'm still not fully convinced, because a) when I set a proxy I'm doing it to never be bothered with governance (but once a year might be ok) and b) I'm afraid even less people will vote and that makes STEEM-like takeover a lot easier - for that problem I think we should closely monitor voting participation rate once we implement the feature. On technical side I see two things. In order to avoid massive expiration in the same block (and resulting major shift in effective votes) we should distribute the first expiration date over 6 months period. F.e. if you last voted 2nd May 2017 then your first expiration date will be planned HF25 date + 5 months and 1 day. Second thing: assuming you've reached expiration, all your governance votes will be cleared. This is safer since we are not introducing any new mechanism, just using existing one for new purpose. It also means that you won't be able to just recast old votes once you wake up from slumber, because those votes will be gone. But that's for the better - whatever reason you had to vote for what you did might have lost its relevance while you were out of touch with Hive.

Changing 5 minute vote window:

I'm in the "no curation rewards whatsoever" camp, but still I see that move as a positive change. It shouldn't be too complicated. Nothing to add here.

Further nonconsensus work in hived:

There is so much to do here that I'm not going to describe it, but the points leading to "modular hivemind" are pretty important. The main question here is the performance, but assuming all goes well, this is also the way to create true lightweight full node with pruning - the thing that a lot of other cryptos had for years. It should also enable "compressing" the requirements of hivemind since potential of having block log in the same DB storage with state and hivemind's 2nd layer data means you don't need to consume as much disk space (now you need large file block log, the same data in AH node and a lot of the same data in hivemind; with the change you could have all-in-one and f.e. keep unedited posts as links to comment_operations that spawned them, no more copying of that large data).

Pitfall of state as hash in relation to consistency checking in DAPPs:

The proposed periodical publication of hash derived from state can make future changes of the application a lot harder if not impossible. You can't simplify and change internal representation of data unless you can make sure you are still capable of computing exactly the same hash. It can also block some optimizations. F.e. if developer spots that he can push some rarely used data to external storage he would be very much willing to do so. "Not so fast!" says the reality - "You need that data to compute hash". Since state is internal juice squeezed out of consensus, it shouldn't matter how it looks on the inside. What matters is if the two instances of the same DAPP continuously agree about the validity of incoming operations. In case of 1st layer the disagreement in internal state shows up as one of the nodes discarding transactions accepted by the other node, but that can happen months after the actual point in time when first disagreement in state was introduced. It certainly is a problem during debugging, but not so much of a problem for keeping the chain consistent. The equivalent of that situation on 2nd layer would be to keep track of which operations were accepted as valid for particular DAPP. That in turn only requires DAPP developer to keep a rolling hash of stream of bits meaning valid-invalid and publishing it periodically. Such solution would not put any constraints on internal representation of the state and would still provide confidence that all instances that agree on which operations were valid also agree on deeper level (at least to the same point as we have for 1st layer).

Front-end work:

I'm back-end all the way, however having someone nearby that can quickly react on the changes in API would be a godsend. I have to admit I'm guilty of making fixes that broke some (invalid, mind you) uses of the APIs, f.e. this issue.
I do realize that all changes like this should be announced in advance, but that would be in ideal world when you need to make such change once every couple of months. When you need to do that couple times a day the story looks very different. It became a bit more quiet recently, but still changes and fixes that can potentially break something in GUI happen a lot. Having someone who can spot the problem, talk it out with back-end in person and work out an acceptable solution would be very nice (as a side note - when someone tells you remote work in IT is just as effective as work on site, don't believe in it, it is hardly ever true and even then only in very narrow use cases :o) ).