No problems reported in a month. Closing as fixed.

if the current function behaivor is acceptable, the fixes left seem to be just documentation updates. this does overlap with bug #64516, but the following could be useful for the optimset/get help:

1 - optimset should list the current Valid Parameters (as it does), and also mention the fact that the list can be extended by the user or other packages (maybe with a redundant note there stating that the full 'active' parameter list can be obtained from a no argument call to optimset.)

2 - should explain (a) the automatic matching process, (b) the expected behavior when an ambiguity occurs, (c) expected behavior when an unambiguous but unknown parameter is specified, (d) that automatic matching will ignore any non-standard/unknown parameters.

3 - state that optimset/get cannot be used to set/query any ambiguous parameters, they can only be accessed manually using dot notation (is that the correct name?)

4 - a warning in optimset that that the optimization options structure is intended only for manipulation of known parameters by optimset/get, and that unknown parameter creation, creation of ambiguous parameters, and loading/unloading packages that change the known parameter list after creating an optimization options structure can result in unpredictable/undesirable behavior.

the comment #8 change to optimset still allows arbitrary parameters to be set, so long as there is no matching ambiguity with default parameters.  if there is, the change will make that an error. 

I don't think any Matlab parameters have full-name ambiguities with current Octave parameters. Are you aware of any that do? If not, then Octave will still allow you to set those properties using optimset and retrieve them with optimget. 

In the case that you still need to set arbitrary field names, the dot convention still functions with both Octave and Matlab (and it's the only way to work with them in Matlab).

if that doesn't cover your user case concern, please explain further so we can better understand

Imho, the behavior after Rik's change is more consistent than what is proposed in comment #7.
`optimset` prevents such options from getting set now. So, `optimget` should behave the same way.
It is true that it's possible to add additional fields to the options structure like to any other structure. But in this case, it seems reasonable to me to expect from users to access these fields like they would do for any other structure (i.e., with `.`-indexing).
Anyway, it might be reasonable to discourage mixing direct structure access with using `optimset` and `optimget`. But that's a documentation issue and probably fits better in bug #64516.

I'm ok with set issuing an error, but would it make more sense for optimget to still issue a warning? it will return empty if it's ambiguous unless it's an exact match, at which point it will issue an warning but return the exact match value as well. Perhaps the warning message could be updated to mention the ambiguity and clearly re-state the name of the field being returned?

This change might break compatibility with code written for older versions of Octave. (Code that previously succeeded with a warning now fails with an error.)
I agree that this change likely helps to catch unintentional user errors. Imho, it should be mentioned in the NEWS file though.

looks like optimget returns an empty array unless something with the actual ambiguous name is present. since it's currently valid to set arbitrary fields, an error being issued might prevent querying a manually set parameter with optimget:

>> a = optimset('max_fract_change',1, 'max_rand_step',2, 'MaxFunEvals',3, 'MaxIter',4)
a =

  scalar structure containing the fields:

    max_fract_change = 1
    max_rand_step = 2
    MaxFunEvals = 3
    MaxIter = 4

>> optimget(a, 'max')
warning: optimget: ambiguous option: max (max_fract_change, max_rand_step, MaxFunEvals, MaxIter)
warning: called from
    optimget at line 55 column 5

ans = [](0x0)

>> a.max = 6
a =

  scalar structure containing the fields:

    max_fract_change = 1
    max_rand_step = 2
    MaxFunEvals = 3
    MaxIter = 4
    max = 6

>> optimget(a, 'max')
warning: optimget: ambiguous option: max (max_fract_change, max_rand_step, MaxFunEvals, MaxIter)
warning: called from
    optimget at line 55 column 5

ans = 6

I just discovered that optimget() has the same issue.  Changing the summary to reflect that.