Should not conflict on unmodified objects

[naoliv]

I am unsure about this.
With the attached file search for id:326787327 and then run Update selection
JOSM gives some conflicts although I have not modified anything.
Shouldn't JOSM just update it to the current state in OSM?

Repository Root: http://josm.openstreetmap.de/svn
Build-Date: 2015-03-18 02:31:09
Last Changed Author: Klumbumbus
Revision: 8145
Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Relative URL: ^/trunk
URL: http://josm.openstreetmap.de/svn/trunk
Last Changed Date: 2015-03-16 23:07:23 +0100 (Mon, 16 Mar 2015)
Last Changed Rev: 8145

Identification: JOSM/1.5 (8145 en) Linux Debian GNU/Linux 8.0 (jessie)
Memory Usage: 247 MB / 10206 MB (145 MB allocated, but free)
Java version: 1.7.0_75, Oracle Corporation, OpenJDK 64-Bit Server VM
Java package: openjdk-7-jre:amd64-7u75-2.5.4-2
VM arguments: [-Dawt.useSystemAAFontSettings=on]
Dataset consistency test: No problems found

Plugins:
- Create_grid_of_ways (30892)
- ImageryCache (30892)
- OpeningHoursEditor (30962)
- PicLayer (30962)
- SimplifyArea (30962)
- buildings_tools (30955)
- conflation (0.1.7)
- contourmerge (1012)
- download_along (30892)
- editgpx (30892)
- geotools (31000)
- importvec (30892)
- jts (31002)
- log4j (30892)
- measurement (30892)
- merge-overlap (30988)
- opendata (31050)
- pbf (31010)
- pdfimport (30892)
- poly (31056)
- reverter (30990)
- scripting (30702)
- todo (29154)
- turnrestrictions (31034)
- undelete (30892)
- utilsplugin2 (31040)

[skyper]

I can reproduce.
Strange, as "Update data" does not create any conflict in this case and #4518 asks for exactly this behavior with "update data".

[GerdP]

I think the conflict is that the relation in your file still refers to the way 326787327 while the server version doesn't.