This is basically a consequence of using REST sub-collection for nested attributes config overrides are published as sub-collection of the versioned profile they belong to so, when making a change to one of those from the UI, that change is POSTED straight away to the sub-collection (no notion of transaction) which means that it is applied straight away to the current versioned profile. if that guy happens to be published then we effectively modified a published profile. another side effect is to make the content of versions history rather confusing.