A small example of what you want would be helpful.

@unproductive The GUI isn't the only interface to Maple. I mainly use tty Maple, running scripts written using maplev-mode for Emacs.  Have also written a crude Maple extension for org-babel.

@HuanLuong The problem is that the assigned port names are duplicates of the corresponding signal names. You can workaround this by changing all the port names, say append an underscore (_) to the current name; with that change the Dimensional Analysis returns with no errors.  Because it is natural to name a port for the signal that connects to it, this should be handled better by the template.  That will be fixed. 

@Britzel Note that the operands of a piecewise are numbered left to right, however, the 2D display of a piecewise swaps the conditions and expressions. The first operand of a piecewise, op(1, pw), is a condition, but it appears on the right in the 2D display. 

An example would be helpful.  By "cases" do you mean a piecewise expression? Selecting a subexpression from a piecewise may be tricky, without using assuming.  The op procedure can be used to access any subexpression, however, doing so makes the selection dependent on the order of the terms of the piecewise, which may or may not be guaranteed upon recalculation.  It might be useful to have a procedure that evaluates just the conditions of a piecewise, but not the corresponding expressions, given equations that define the dependent variables. For example 

   evalpw(piecewise(x < 0, x, x^2), [ x = -1 ]);

might evaluate to x.

Please upload the msim file, or send it to Maplesoft support.

@Carl Love Clever use of the two-argument version of eval, better than my ugly double-forward-quoted method. Not that I'm likely to use either.

@mmcdara I find the operation of binary element-wise operators on sets a bit strange. Consider

(**) {a,b} +~ {c,d}
             {a+c, b+d}

While this may seem reasonable, it may not be well-defined. The result depends on the order of the two sets, which traditionally is indeterminate. Note that the zip operator, the functional analogue of a binary element-wise operator, does not operate on sets for this very reason. If Maple had extended that to element-operators, than it could have made your original operation valid, because the right side, being a set, could be considered an atomic element and so applied to the both sets in the left list.

@tomleslie I'd probably write that as

if not x :: 'realcons' then
    x := b;
end if;

An advantage of using the :: operator is that it won't give a weird error if x is NULL. Note that type 'realcons' may call evalf, which is relatively expensive (probably not a factor here, but sometimes an issue).

@nm To get an idea what is happening, do the following

(**) infolevel[odetest]:=5:
(**) (odetest)(my_sol,ode);                                                                                                                                
odetest: Performing an implicit solution test
odetest: Performing an explicit (try hard) solution test
odetest: Performing an implicit solution (II) test
odetest: Performing another explicit (try soft) solution test
odetest: Trying zero recognition...
(**) (odetest)(subs(C1=_C1,my_sol),ode);                                                                                                                   
odetest: Performing an implicit solution test
odetest: Trying to eliminate constants using the order: [_C1]
odetest: Trying to eliminate _C1
odetest: Successful elimination of _C1
odetest: length of implicit solutions after isolating _Cn constants: 106
odetest: length after collecting objects and simplifying coefficients: 106
odetest: length after Solve w.r.t yn: 64
odetest: length after collect @ normal @ eval the ODE at the implicit solution: 0
Successful implicit test

As you note, some solutions can be successfully handled with arbitrary integration constants; however, as the original problem shows, that isn't always the case.

@Carl Love That's close to what I'd do. It would be what I'd do, but didn't realize that x[type] was a valid type. So my version is a bit longer.

remove(hastype, A, 'specindex(numeric,x)');

Note that this version works nicely if you have to match multiple base symbols:

remove(hastype, A, 'specindex(numeric,{x,y,z})');

If you don't care about the type of index, do

remove(hastype, A, 'specindex({x,y,z})');

@mmcdara I'm not sure but have tested ExcelTools using command line maple on Linux with Maple 14 and Maple 2018 and on Windows with Maple 15 and 2018. Import and Export worked fine.

Maple14 and up can use ExcelTools in command-line Maple.

@Muhammad Usman Carl told you how to fix it.

*Followup* I hadn't realized you provided a third update.  Change the &* operators to the dot operator (.). 

@Carl Love It is unfortunate that evalm doesn't raise an error when operating on an rtable, however, I wonder whether that occurs enough to warrant a change.  If a user is using evalm to convert an rtable to an array (old style array), they would be better off using convert; at least it's use would be clear.