what is wrong with symbolic assignment?

Question

I have big code and i noticed a bug in my code without any syntax error. I describe it using the following example:

I=sym(eye(3)); %I is Identity 3by3
a=sym(zeros(5,1)); %a is column matrix

then :

a(1)=I;

which should give an error but the result is:

a=

 1
 0
 0
 0
 0

it means that matlab assigns a 3x3 matrix into an element of a!!!

what is wrong?

I tried the same but know using I and a both of double type now it gives an error which is correct.

Answer 1

--Converted from comments---

What's the problem

In general attempting to assign something of size 3x3 to a smaller array will cause Matlab throw an error. however with sym the following happens:

I=sym(ones(3));
a=sym(zeros(5,1))
n=3
a(1:n)=I

a =

 1
 1
 1
 0
 0

For some reason with variables of class sym no error is caused. If more elements are given in I than will fit in the n assigned positions of a. It will assign the first n values of I to a

Why

In the subsasgn method for in the classdef of sim (subsasgn being the method used for the syntax a(1)=I) no check on the size is present (not entirely true as if a is an empty sym array and error is caused) The function iterates through the n locations in a assigning the first n values of I to each individual position in a.
For example the code above it is equivalent of performing a(1:n)=I(1:n), which would be the command to generate this behaviour with double.

Is this intended?

Not a clue!
The help documentation doesn't mention this different behaviour so I assume it is a bug, a service request has been put in for either documentation or fixing.

What can be done

Be careful - sorry but that is all I've got to avoid this problem

EDIT -- Support request was answered ---

Yes you are right; I apologize for the inconvenience this unexpected behavior might cause. This indeed appears as being inconsistent with base MATLAB behavior. Thank you for bringing this to our attention as this behavior should be documented (if not issuing a warning). I will create a relevant documentation enhancement today.

...seems like it is soon to be not a bug but documented behaviour