This appears to be blocked on having the spec-side discussion with other vendors, or perhaps a lack of interest from them.

A search for ".dataLoss" in httparchive:har.2017_03_15_chrome_requests_bodies gives only 4 hits, where just 1 was non-bogus. That's http://www.go211.com/ including https://docs.google.com/static/document/client/js/3585601610-kix_main_i18n_kix_core.js, which has this code:

iI.prototype.La = function(a) {
    M(this.C);
    if (a.dataLoss && a.dataLoss != di) {
        var b = {};
        b.dataLoss = a.dataLoss;
        b.dataLossMessage = a.dataLossMessage;
        b.optinBackup = xIa();
        b.requestContext = this.ea;
        b.unsavedChanges = Qmb(this.Ha);
        this.Ha.info(Error("upgradeNeeded after dataLoss"), b)
    }
    this.Z && this.Z(a)
};

Removal would not be breaking (exception-throwing) but would presumably result in something less good happening in the case of corruption detected on upgrade.

We added these at the request of Google properties. We'll need to check with those to see if they're still in use, since those are unlikely to show up in httparchive.

... or not, let me actually read your comment where you cite docs.google.com/kix (the document editor). Yay for httparchive!

We should also review data loss rates and see how often we report something at this point. 

We should also kick off discussion w/o other vendors again. This approach was always the least-bad but not a design we particularly liked. Perhaps there will be a better way to signal this.

Sounds good, this seems quite unlikely to be a serious real-world compat pain for any other browser, so if it takes a while to figure out what to do with this, that's OK.