I agree on a couple of points.  First, Octave's handling of very large indices needs to be better.  Second, the problem can be broken up in to different regimes where, unfortunately, Octave is performing poorly each time.  For indices greater than intmax, as Dan has pointed out, the integer value reverses sign and becomes negative and is generally handled poorly.  That is the first thing to fix.  The second regime is indices greater than flintmax but less than intmax where there can be a loss of precision.  A warning about using linear indexing in this regime would be a good idea.  In addition, to warning about linear indexing it should suggest the alternative of using full subscripts (A(i,j)) which very likely preserves full precision.

Interesting warning.  The issue is discussed here:

https://savannah.gnu.org/bugs/?54405

and I believe there is a bug in the way float is cast to an integer for which I've attached a patch:

https://savannah.gnu.org/bugs/?54414#comment7

As an ancillary item, I posted the following regarding the float vs int64/uint64 dilemma for "native" arithmetic:

https://savannah.gnu.org/bugs/index.php?54567