Let's first investigate what exactly is going on.
The functions V__tot and similar all take a unitless quantity t as their argument, as you can see by evaluating, for example, V__tot(1.3). In the integral, however, you specify the lower and upper bounds for t, the argument of V__tot, as T__1 and T__2, which are 0 and 1 ms. (I should note here that 0 is a special case - it can only be unitless in Maple for technical reasons - but the int command interprets the range as expressed in units of time.) So the int command tries to substitute time values for t, which causes the sin command inside V__tot to fail, as it does on the command line if you evaluate V__tot(1.3*Unit(ms)). Maple decides that that's an expression it can't integrate and merely takes the unit, V2, out of the integral. So we have now evaluated the integral to some unevaluated integral times the unit V2. This is then divided by T__2 - T__1, a duration, to obtain an unevaluated integral with the unit V2/s. The square root of this then has the unit V/s1/2, which is equivalent to the unit you see. It could be argued that this is correct, because if we could specify the integrand better, the integral would come out to be a duration (it is a unitless quantity, integrated over a period of time, so the dimension is time), its square root therefore has the unit s1/2, and multiplying that with the unit we see gives the unit m2 kg / s3 / A, which is the same as V.
However, this is all of course incredibly clunky and it doesn't lead to Maple giving you the answer you're looking for. So let's talk about solutions. The first option is to make the integral strip off the time unit and add it back on manually. I think the appropriate unit is ms, correct? So we can do that by specifying the lower and upper bounds as T__1/Unit(ms) and T__2/Unit(ms) and multiplying the integral by Unit(ms). This appears to lead to a correct result (of sqrt(2)/2 V). But this is, in some sense, cheating: we just remove the units manually and then put them back on. It's possible to do better.
The second option is to make V__tot accept an expression in terms of time, rather than a unitless quantity. For this we need to do two things:
- Redefine V__tot_AC(t) := A * sin(omega * t);
- Be very careful to never submit a unitless quantity into V__tot or V__tot_AC.
The latter issue appears, for example, when we try to plot these functions: the only way I can think to do this is to change the command to plot(V__tot(t * Unit(ms)), t = 0 .. 5) (and similar for V__tot_AC). It also appears when we want to do the integration: just entering V__tot(t) already causes an error. However, we can prevent the error by using unevaluation quotes (single forward quotes) around V__tot(t): int('V__tot(t)'2, t = T__1 .. T__2) evaluates no problem. This leads to the same result of sqrt(2)/2 V.
You don't write what version of Maple you are using; if it is version 2017, you can use another trick to get around some of the problems here. In 2017 we introduced the Units[Simple] package as an alternative to Units[Standard]. The most important difference between the two is the following: the Units[Standard] package assumes that every unassigned variable, such as t, represents a unitless quantity. The Units[Simple] package does not. This restriction may have played a role in your decision to define V__tot_AC(t) the way you did, where you included the unit for t in the definition, rather than it just being part of the value t that the user submits. Indeed, with the Units[Standard] package, you cannot evaluate sin(omega * t), if t is unassigned and omega has a unit of frequency, because the argument to the sine function is then assumed to have a unit of frequency, which is illegal. On the other hand, if you load the Units[Simple] package, it will see the unassigned variable t and not assume anything about it. (It does assume that every unassigned variable has a single well-defined dimension within one expression; if you evaluate (t + 5 kg) * (t + 5 ms), then Maple will complain: the first factor implies that t must be a mass and the second that t must be a duration.) So compared with the Units[Standard] solution, you don't need to worry about what arguments you submit to V__tot so much: if the argument can be a duration for some assignment of units to your variables, then Maple will accept it. So item 2. above is not so important anymore. In particular, you get the correct answer for V__tot_rms by only removing the unit ms from the definition of V__tot_AC, no quoting needed anywhere.
Finally, for the upcoming version of Maple (which is still some time away!) we have overhauled plotting with units somewhat; if you use my suggested definition of V__tot and you use Units[Simple] so that you don't need to worry about evaluating V__tot on symbolic arguments, you will be able to get the correct plot just by writing plot(V__tot(t), t = 0*Unit(ms) .. 5*Unit(ms)) or, if you prefer, plot(V__tot, 0*Unit(ms) .. 5*Unit(ms)). We feel this is a more natural way to use units in plots.