Nudging is not sufficient: no saving should be possible after the change of statement value if no changes are done in the reference section. Most of the references used "retrieved" property as part of the reference so this property has to be updated for each change of the value.

The obligation of changing the reference when changing the value is a key point in vandalism prevention. First this implies several modifications so lazy vandals won't be interested and then several modifications can increase the detection of the change and increase the probability of a check.

The best solution would be the impossibility to change a statement once published. This rule would have a real impact as WD reliability improvement, as people can trust data imported from authoritarive sources by reliable contributors. Using filters based on sources or dates (publication date or retrieved date), it would be possible to always select the same data, so if the data was checked once, this allows a trust for the future without a permanent monitoring of item's modifications. Vandals can add wrong statements or even delete true statements, the choice of displaying one WD data in WP will always be respected.

I didn't know about the "award token" option!

Yes, we should do something along these lines. However, I think there are a number of situations to be addressed:
(1) The edit may be a clean-up which has no material impact on the value of the statement (especially for quantity values, adjusting the precision, or for URL's adding/removing a trailing '/' or something like that). It is probably hard for software to understand this distinction, so I think despite Snipre's concern above we will always need an option (a checkbox or something) to let the user preserve the existing reference unchanged.
(2) For item-valued statements, an edit to fix a redirected value should definitely preserve the references. This may or may not be easy to detect automatically.
(3) The original data insertion may have been incorrect in some respect relative to the reference (for example linking to the wrong item or for any datatype simply having the wrong value somehow). Again a correction to match the original reference would not require any edit of the reference (other than possibly updating the "retrieved date" value).
(4) A qualifier like "end date" is added to the statement. This should perhaps be supported by a new reference, but it wouldn't invalidate the old references on the statement.

The real concern is edits that change the value in a material respect. In this case I think the default behavior should be to preserve the original value with a deprecated rank, rather than to actually delete it. So the UI that I think would work best is:

• For a statement with no references, allow edits as now.
• For a referenced statement, by default when the value or qualifiers are changed, preserve the original statement with its references but set rank to 'deprecated', and remove all the old references on the new statement (and nudge the user perhaps to add new ones).
• But provide a checkbox to assert that this is not a material change so that the original references are preserved and the 'deprecated' statement need not be created.

Make sense?

@ArthurPSmith The only point I would agree with your comment is the case of redirection in case of merging. Even for the addition of end date qualifier I would not accept a change without a modificaiton of the reference: this piece of informetion requires a reference too and was not present in th eoriginal source (the normal case). So this is wrong to add a new information using a reference not mentioning it.

We can still discuss about the modification of the reference section because very few contributors are correctly adding reference data.