Should xdg_surface.ack_configure allow excessive acks?

xdg_surface.ack_configure is mostly permissively worded, with no restrictions. It describes how you use ack_configure to respond to a configure event, passing the serial in, and mentions that you may send multiple back-to-back requests, or only ack the most recent one.

I noticed (whilst hacking up a really dumb test client to add xdg-shell support) that if you do this:

struct surf {
    uint32_t last_configure;
};

xdg_surf_listener.configure = (struct xdg_surface *surface, uint32_t serial) {
    surf->last_configure = serial;
}

while (true) {
    wl_display_dispatch();
    glDrawArrays();
    xdg_surface_ack_configure(xdg_surface, surf->last_configure);
    eglSwapBuffers();
}

then both Weston and wlroots will reject the second ack_configure, as they no longer record the serial as needing to be acked. Mutter, however, accepts repeated ack_configure with the same value, as it still considers the serial 'valid'.

I'm not sure what KDE or QtCompositor do, since I don't have easy access to them, neither Exosphere.

I think I would be in favour of explicitly making it erroneous to accept multiple ack_configure values (i.e. codifying the Weston/wlroots behaviour), but would like to scout opinions on this first.

Relatedly, it would make it easier for clients if servers also guaranteed that a serial of 0 was invalid and would never be sent, since it means that they could just keep a uint32_t serial to determine if they needed to ack, rather than uint32_t serial + bool is_serial_valid.

cc @jadahl @emersion @romangg @eskilblomfeldt @afrantzis