As mentioned already, this approach is extremely prone to bugs and unexpected behavior. As soon as someone calls a variable "table" or "who", the posted code will fail with strange error messages. I'm convinced, that the who approach means drilling a hole in your knee.
Unfortunately I do not work with Simulink and cannot suggest a better solution. Is it possible to export the data as fields of a struct? Or why not creating the table directly in Simulink? Two cell arrays would be smart also: One with the data and the other with the names.
What ever you do, avoid accessing variables dynamically. If you program is useful, others will use it also. Then any dynamical search for variables in the workspace can and will collide with other software. The new users will be extremely surprised and frustrated, because it is a mess to fix your software such that it does not interfere with other codes or any existing variables in the workspace. A fundamental idea or reliable software is to reduce the interaction with unrelated other software. An automatic import of some variables matching a specific name pattern can work under some circumstances, but if it fails, it can destroy work seriously and massively.
If your code is just a little hack and it will not be used for productive work - so it is a simple fun project -, tricks like the dynamic access of the BaseWorkspace cannot do a lot of harm. But even then I recommend to use clean programming techniques only, because it helps to be firm with a good programming style.
Note: If you assume, that my answer is emotional - yes, it is. I've seen too many "working" code which suffered from eval, global variables and hardcoded dependency to GUI elements:
x = get(FigH, 'Children')
result = str2num(get(x(17), 'String')) + eval(get(x(31), 'String'))
Brrrrr. As soon as the GUI is modified or as a new Matlab version stores the children in another order, the code fails and is impossible to maintain.
Sorry that this is not a direct solution to your question. But as a brave programmer I recommend to modify the problem instead of solving it in a fragile way which is known to cause more troubles soon.