Incorrect xdg_output logical size for scaled outputs

When an output is scaled, e.g., by a factor of 2, my expectation (based on my understanding of the xdg-output spec) is for the logical size reported by xdg_output to be ~half the physical size (i.e., the current wl_output mode). Here are the relevant parts from the xdg-output spec:

For example, a surface without any buffer scale, transformation
nor rotation set, with the size matching the logical_size will
have the same size as the corresponding output when displayed.

and:

For example, for a wl_output mode 3840×2160 and a scale factor 2:
- A compositor not scaling the surface buffers will advertise a
  logical size of 3840×2160,
- A compositor automatically scaling the surface buffers will
  advertise a logical size of 1920×1080,
- A compositor using a fractional scale of 1.5 will advertise a
  logical size of 2560×1440.

However, by default Mutter reports the same logical and physical sizes:

interface: 'wl_output', version: 3, name: 4
	x: 0, y: 0, scale: 2,
	physical_width: 290 mm, physical_height: 170 mm,
	make: 'SHP', model: '0x144a',
	subpixel_orientation: unknown, output_transform: normal,
	mode:
		width: 3200 px, height: 1800 px, refresh: 59.981 Hz,
		flags: current preferred
interface: 'zxdg_output_manager_v1', version: 3, name: 5
	xdg_output_v1
		output: 4
		name: 'eDP-1'
		description: 'Built-in display'
		logical_x: 0, logical_y: 0
		logical_width: 3200, logical_height: 1800

Note that setting the scale-monitor-framebuffer feature corrects this behavior.

If I am not misunderstanding the xdg-output spec, advertising a properly scaled logical size would be the spec-compliant behavior for Mutter, given that it autoscales buffers (i.e., case 2 in the spec example). Note that this can be independent of any fractional scaling support, i.e., spec example 3 (I guess the compositor can disallow any scale values that cause problems in this regard). The scaled logical size is reported correctly by Weston, KWin, wlroots, Mir.

The current behavior confuses clients (e.g., Wine Wayland) that may want to infer the effective output scale from the logical/physical sizes. If the current behavior is required for legacy reasons (e.g., XWayland,) perhaps it makes sense to only be applied to XWayland clients by default?

Thoughts?