Forgotten to say:

The bug persists if
      T[] data() { return dat[0..len]; }
is replaced by
      T[] data() { return dat; }
but disappears if you delete this line and do
      alias dat data;
instead.

This is a TERRIBLE bug report! The test case is really complicated, and very far from minimal. I've reduced it slightly so that it at least asserts when it fails.
It also fails on D1, at least as far back as 1.020.

If you comment out the line marked 'FAILS' and replace it with the line marked 'WORKS' it will work correctly. I would appreciate if someone could cut this test case down. I think it might be important. (OTOH it might just be luck that it works at all, it might just be reading whatever's on the stack).

----
class Stack{
    private uint len;
    private uint[] dat;

    uint[] data() { return dat[0..len]; }

    int length() { return len; }

    void push(uint t) {
        if(dat.length<=len) dat.length=dat.length+32;
        dat[len]=t;
        len++;
    }
    void pushn(uint n) {
        len+=n;
        if(dat.length<len) dat.length=len+32;
    }
}

class termmem{
    Stack mem;
    this(){mem=new Stack;}

    uint cell(uint addr) { return mem.data[addr]; }
    uint head(uint addr) { return cell(deref(addr)); }

    uint deref(uint addr) {
        for(;;) {
            uint c=mem.data[addr];
            if(0!=(c & 0xf000_0000)) break;
            if(c==addr) break;
            addr=c;
        }
        return addr;
    }
    uint var() {
        uint d=mem.length;
        mem.push(d);
        return d;
    }
    uint f(uint fnId, uint[] arg...) { return f_(fnId,arg); }
    uint f_(uint fnId, uint[] arg) {
        uint a=fnId>>28;
        assert(a>0x8);
        a-=0x8;
        assert(a==arg.length);
        uint r=mem.length;
        mem.push(fnId);
        for(uint i=0; i<a; i++) {
            uint w=arg[i];
            uint t=w>>28;
            assert(0==t || 0x8==t);
            mem.push(w);
        }
        return r;
    }

    uint copyfskeleton(uint _addr)
    {
        uint r(uint a) {
            a=deref(a);
            uint c=head(a);
            uint t=c>>28;
            if(t==0 || t==0x8) return var();
            t=t&7;
            uint d=mem.length;
            mem.push(c);
            mem.pushn(t);
            for(int i=1; i<=t; i++) {
// FAILS:
      mem.data[d+i]=r(a+i);
// WORKS:
      //uint rr=r(a+i); mem.data[d+i]=rr;
            }
            return d;
        }
        return r(_addr);
    }
}

void main()
{
    termmem T=new termmem;
    uint S(uint x) { return T.f(0x9000_0000,x); }
    uint P(uint x, uint y) { return T.f(0xa000_0000,x,y); }
    uint x=T.var;
    uint y=T.var;
    uint t=S(P(S(S(x)),x));
    uint s=S(P(S(S(x)),S(x))); // if commented out, bad behaviour disappears
    uint u=T.copyfskeleton(t);
    assert(T.mem.data[0x17]==0x18);
}

This is not a bug.

There's no sequence point in "mem.data[d+i]=r(a+i);", so the order of evaluation of mem.data[d+i] and r(a+i) is unspecified. r calls both mem.push and mem.pushn, both of which may lead to reallocations of mem.data, possibly moving the array to a completely different location. Thus the behaviour of the code depends on whether r(a+i) or mem.data is evaluated first.

The "bug" is no doubt due to the mem.data getting evaluated first, since doing the temporary assignment forces it to be the other way around.