In practice, how eventual is the "eventual consistency" in HRD?
What's the worst case if you get inconsistent results?

Does a user see some unimportant info that's out of date?  That's probably ok.
Will you miscalculate something important, like the price of something?  Or the number of items in stock in a store?  In that case, you would want to avoid that chance occurence.

From observation only, it seems like eventually consistent results show up more as your dataset gets larger, I suspect as your data is split across more tablets.
Also, if you're reading your entities back with get() requests by key/id, it'll always be consistent.  Make sure you're doing a query to get eventually consistent results.
I am in the process of migrating an application from Master/Slave to HRD. I would like to hear some comments from who already went through the migration.

I tried a simple example to just post a new entity without ancestor and redirecting to a page to list all entities from that model. I tried it several times and it was always consistent. Them I put 500 indexed properties and again, always consistent...
I was also worried about some claims of a limit of one 1 put() per entity group per second. I put() 30 entities with same ancestor (same HTTP request but put() one by one) and it was basically no difference from puting 30 entities without ancestor. (I am using NDB, could it be doing some kind of optimization?)

I tested this with an empty app without any traffic and I am wondering how much a real traffic would affect the "eventual consistency".
I am aware I can test "eventual consistency" on local development. My question is: 
Do I really need to restructure my app to handle eventual consistency? 
Or it would be acceptable to leave it the way it is because the eventual consistency is actually consistent in practice for 99%?