Further experimentation makes me think the following.
For attributes, first it looks for get/set methods, then if none are found it directly accesses the class members.
However, in looking for setter methods in particular, it does not make a completely correct decision which to use based on the type of the parameter. In my case I had multiple array type attributes on a plugin object class. I also had a setter with a List<T> signature and an overload with a T[] signature. Some of my property sets from the JavaScript worked and some failed with a script Array to Java List conversion failure. To work around this reliably I had to eliminate the List<T> setter methods so that only the attribute setter with the correct signature could be found. I suspect this is an issue in the Rhino code where it just takes the first setter returned by the reflective inspection of my class rather than looking to see if one with a compatible parameter type is available.
So, I have been able to resolve my issue, but there is some indeterminism in the selection of overloaded setters with Rhino that should be investigated and resolved.
I'm marking this thread as answered but if any of this is incorrect, it would be good for someone on the VMO team to provide that information.
