We expect index numbers to be:
- complete. We hope to see all the ops that are going to the blockchain.
- sequential: That is operation n+1 never happens before operation n. Although n+1 and n may happen at the same time. And if n+1 exists then n should exist. Things happen at the same time when they are part of the same transaction and may happen at the same time when they are in the same block.
- consistent. We should get the same values and order no matter which host we use (at least within the context of the same blockchain).
Now, #3 is broken because of something outside of scope of Beem. I don't think you should put too much time into working around something that is probably a bug. Documenting that this natural assumption (#3) is wrong (hopefully temporarily), is a good idea, though.
If you are going to give the API users #1 #2 #3 by calculating and deciding on a order in a way that is independent of the Steem RPC node, then we could continue to use the history index number as a key to our transactions we store in our app's database's.