Suppose we make the two assignments,
> x := Vector[row]([1,2]);
x := [1, 2]
> y := Vector[row]([1,2]);
y := [1, 2]
And now we assign to an entry of x,
Most people will usually want that the corresponding entry of y to not get assigned by the above assignment to x. So, Maple has two separate and distinct Vectors [1,2] when x and y are created.
if foo = bar then
will do a comparison for identity, ie. are they the same object in memory. But as just seen, they are not. They are distinct, so that their respective elements may be changed independently.
So, what's been noticed is that mutable objects (objects whose elements may be changed or altered) are generally distinct in Maple.
The routine is() can do some mathematical inference that evalb(..=..) does not do. Originally, is() was a mechanism for query properties, but perhaps it's been becoming mathematically smarter. It's not an unreasonable expectation for is() to be able to handle this query. But, as it happens, it hasn't (yet) been taught to do that.
One might ask, why does if foo=bar then.. make the "object identity" query evalb(foo=bar) rather that the LinearAlgebra:-Equal(foo,bar) query? Well, it's consistent with how most all other objects are treated in that operation. And if the implementation were reversed then someone would complain about that, and an alterntive syntax would have to be used in order to force the specific identity query on Matrices/Vectors, etc.
The Maple help system doesn't really make it easy to figure out what the `=` means in if foo=bar then..