I agree.  I think this bug is complete. Marking as fixed and closing report.

Instead of "synonymous to" I would write "equivalent to".  I like the word "synonymous", but there are many non-native English speakers who use Octave and "equivalent" is probably easier to understand.

You use "(not yet fully implemented)" to describe a number of properties.  Is "fully" accurate?  That implies that there is partial implementation.  It might be better to say "(not yet implemented)" if the only thing that can happen is that a user can change the property value.

And another change that fixes loading figure files that have been saved before "positionconstraint" was added:
https://hg.savannah.gnu.org/hgweb/octave/rev/f9b5357f4a7e

(Savannah is very irresponsive for me today. So I'm not sure if that change actually made it into the repo.)

comment #14:

> I wasn't aware that gnuplot is used for printing the graphics for the manual even if Octave was configured with Qt. Is this intentional?

During the 5.2.0 release I stumbled over that one too.  If no X server is available, even configured with qt, gnuplot is taken to build the documentation images.  For buildbot slaves this might always be the case.

Buildbots seems to be complaining about "activepositionproperty".  This works with OpenGL toolkits, but it seems like some work might need to be done for gnuplot toolkit.

And another one for the positionconstraint property here:
https://hg.savannah.gnu.org/hgweb/octave/rev/af912e78ce43

It should probably be followed by a changeset that replaces "activepositionconstraint" with "positionconstraint" in all .m files.

I shouldn't have added "contextmenu" to the axes and scatter properties. Instead it should have been a base property from the beginning. I fixed that and also let "uicontextmenu" be mirroring the new "contextmenu" property here:
https://hg.savannah.gnu.org/hgweb/octave/rev/e55ff14249c3

@Rik: "nextseriesindex" and the other two "*index" properties have to be handled differently. "nextseriesindex" is a read-only property (not just temporary but also in Matlab). The other two can be set in .m files.
The new scatter object already uses the "nextseriesindex" axes property. I think there is no need to do anything in the axes object directly other than holding the value.

Additionally to "uicontextmenu" -> "contextmenu", there are also "position" -> "innerposition" and "activepositionproperty" -> "positionconstraint" that need similar changes. The latter with the small difference that also the value names changed. But the meaning is the same.

@Markus: Thanks for tackling this.  Matlab is always changing their API, sometimes for good reasons, but sometimes it feels like they are just doing it for the sake of change.

I agree that "ruler" objects and any other big changes to the graphics system need their own bug report, or maybe it is a project either on the Tasks or Patches lists on Savannah.

The renaming of the property "uicontextmenu" to "contextmenu" is a classic Matlab make-work project.  Given how many decades of code people have this will be a slow transition.  Still, it should be pretty easy to write a small updater routine that gets called when someone accesses the contextmenu property and either reads or writes the uicontextmenu property.

I added a few more FIXME notes to the patch from comment #1 and (temporarily) set some properties to read-only that don't have any functionality yet. I did the latter to prevent having to deal with loading figure files which otherwise could contain invalid content in these properties.
I pushed the modified patch here:
https://hg.savannah.gnu.org/hgweb/octave/rev/044cea7947db

The attached patch just adds the missing properties. It doesn't supply them with any functionality.

(file #49044)