Pure Contract bug?

[Era Scarecrow]

> Pure does not imply const in D. If you want stronger 
> guarantees, just turn 'test' into a const (or immutable) member 
> function. In D, a function can change anything that is mutable 
> and reachable through its parameters, this includes the 
> implicit 'this' pointer. The reason for this design is simple: 
> There is no need to be overly restrictive, because the 
> additional restrictions are already trivially expressed in the 
> type system. Furthermore, any mutation of a parameter can be 
> turned into a less efficient protocol that only requires a 
> const pure function, so there would be no gain if pure implied 
> const, it would only make pure less useful.
>
> void foo(int* x)pure{*x+=2;}
> int bar(const(int)*x)pure{return *x+2;}
>
> void main() pure{
> int x, y;
> foo(&x);     // those two lines have
> y = bar(&y); // equivalent functionality!
> }

Only external data I was implying, that was not based off the 
input arguments. Examples in the book refer that calculating Pi, 
or the square root of 2 is a constant and will always result in 
the same output, regardless the situation.

Quote TDPL pg 165:
"In D, a function is considered pure if returning a result is 
it's only  effect and the result depends only on the function's 
arguments.

Also, pure functions can run literally in parallel because they 
don't interact with the rest of the program except through their 
result."

So... If we take a struct.

struct X {
    int i;
    pure int squaredPlus(int x) {
        return x*x + i
    }
    alias squaredPlus sqp;
}

    X st(15);

    writeln(st.sqp(0));  //15
    int i1 = st.sqp(10); st.i++;
    int i2 = st.sqp(10); st.i++;
    int i3 = st.sqp(10); st.i++;
    int i4 = st.sqp(10); st.i++;

    assert(i1 == 100); //pass/fail?
    assert(i2 == 101); //pass/fail?
    assert(i3 == 102); //pass/fail?
    assert(i4 == 103); //pass/fail?
    assert(s1.i == 104); //probably pass.

If the compiler can reorder or run these in parallel (for 
optimization) or caches the result the first time (since it's 
suppose to always return the same value), what's correct in this 
case? This afterall isn't synchronized, even if it was, what's 
correct behavior? Am I wrong in understanding this?