Don't know about the rev files, but the downloaded blockchain size can be reduced using the "-prune" option of the client.

Did you modify the make file? Did you put a "(" somewhere where it should not be?
Generally, recipe errors often come along with errors in makefile, path dependencies, missing environment variable declarations etc.
I'm not knowing this particular error though.

What are you talking about?

The bitcoin API is open for everyone who wants to develop with it.
https://blockchain.info/api

Maybe also take a look at the debug.log file. It may contain some helpful bug tracking information on this.

A bank pretty much undermines the decentralized approach of the bitcoin system.
While users new to bitcoin might find it decent to have the responsibility for maintaining their funds at trusted hands and eradicating the need for periodical backups, it is reducing general anonymity and privacy and increasing the probability of a focused attack.

Any system that should meet demands of privacy needs more action from its users, since privacy always means keeping essential data and secrets private. But in my opinion, it's worth the extra effort.

This is pretty normal behaviour.

The other address (1LiwvQeiRxD7pBVsTNjcA21iLfAhUeSdt4) is the return address which is under your control (or the control of your wallet).

A transaction that can't be payed without dividing the available amounts will always result in a payment and a return of the remaining funds. Nothing to be worried about

And for the HD wallet generation: for me worked starting up the client without any wallet.dat file. Then it showed up the "HD" icon in the lower right corner. And afterwards a transaction to an address there.
This is cleaner than trying to convert a wallet or stuff like that.

I did have a similar issue with the new bitcoin client version.

I then reverted to v13.1 and did a rescan of my wallet. All funds reappeared. I transferred them to a new wallet.
For production and high load webservices I keep using the older version since that, as I never had such a problem there.

Hoping there will be some updates soon that fix such behaviour.

I also had a similar issue, for me it sporadically was crashing just after starting up with v14.1.
I had to wait for a minute or two before interacting with the UI and then it worked fine. Might have been some threading issue if the block check, the sync/communication worker and the user want to access data at the same time.