@sand15 The addresses of the names returned by alias() are not the same as the addresses of the original global names. That is why your attempt did not work. (This relates to the magic way that the kernel builtin procedure alias:-BuiltinAlias works.)

An alternative might be,

restart;

alias(f=f(t)):
alias(g=g(t)):

a:=[indices(alias:-ContentToGlobal,':-nolist')];

            a := [f, g]

diff(a,t);

            d     d
           [-- f, -- g]
            dt    dt

I will file a report.

It returned both (as lists) in my Maple 16.02, but not in 17.02.

@John2020 

Download taylor_frontended.mw

And, as alternate, using frontend rather than explicitly freezing,

restart;
with(Physics):

r := x*(diff(theta(t), t))^2+y*(diff(varphi(t), t))^2:
g := (4*(f+T))*(diff(theta(t), t))^2+u*(diff(varphi(t), t))^2:

frontend(solve,[identity(r=g,diff(theta(t),t)),[x,y]],
         [{`+`,`*`,`=`,list,specfunc({identity})},{}]);

           [[x = 4 T + 4 f, y = u]]

@John2020 If you load the Physics package then the name diff is rebound.

I wasn't suggesting that you instead try to freeze calls to Physics:-diff. I was trying to suggest that you'd need to distinguish between Physics:-diff and the original, global name (and try to ensure that it is the latter which gets frozen). I posted my earlier reply from a phone, which is why it is terse. Sorry.

The code I originally provided freezes calls to the name diff, without forcibly referring to the original global name :-diff rather than the current binding of that name. But it will continue to work -- even with Physics loaded -- provided that you refer explicitly to that global name :-diff instead of the rebound diff.

restart;

with(Physics):

r := x*(diff(theta(t), t))^2+y*(diff(varphi(t), t))^2:
g := (4*(f+T))*(diff(theta(t), t))^2+u*(diff(varphi(t), t))^2:

solve(identity(subsindets(r=g,specfunc(:-diff),freeze),
               freeze(:-diff(theta(t),t))),
      [x,y]);

             [[x = 4 T + 4 f, y = u]]

@John2020 So why not provide the additional problematic example!?

It might be that you need to adjust what is frozen, eg. Physic:-diff versus diff or some such thing.

[edit. The above was not adequately clear, sorry. I meant that one might have to ensure that it is not Physics:-diff which is frozen, but the original global name :-diff. I meant that one might distinguish one versus the other.]

As the OP has learned an exact expression can be achieved here, though some of the methodology is not (as yet) explicitly given.

One way in which it can be achieved is through a change of variables under some reasonable assumptions that agree with the supplied plotting range.

This form of exact result does not suffer from the same numeric difficulties under fsolve. This particular form of the exact result can also be evaluated numerically without undesirable small (or float 0.0) imaginary components.

Download inverse_function_with_fsolve_ac2.mw

[edit] In fact the same well-behaved exact form can be obtained even more directly. (The key here is to also pass the lower-bound assumption x0>0.)

@tomleslie The edit I suggested is not too hard to guess, and it causes the code to "run away" for me.

But I agree with you that a worksheet would be better. The OP's last Question was posted with a crucial detail missing (ie. Digits value, which made a significant difference).

@tomleslie I don't think that the OP intended

    if root_r != 0 then

as 1D input, since then it tests a factorial against zero (with unfortunate consequences on whether equations get augmented or not).

It's more likely that the OP intended,

   if root_r <> 0 then

It may even be that the OP used the != syntax in 2D Input in Maple itself, but made the mistake of thinking that literal could be sensibly shown here as plaintext code.

@Jaime_mc2 Why are you using,

   evalf(allvalues(RootOf(HermiteH(7, x), x)));

instead of, say,

   [fsolve(simplify(HermiteH(7, x)))];

Also, would a single solution suffice (if there were infinitely many)? I am wondering also why you are using solve rather than fsolve, when dealing with the equations.

Presumably you intend,
    root_r <> 0
instead of,
    root_r != 0
in the 1D Maple Notation plaintext code that you provided.

The code originally provided runs without error. But after this (reasonable) edit the code runs amok.

@tomleslie Yes, and I had previously added a zip alternative as a postscript to my Answer.

Please show us your problematic code. It could be inlined as text, or a link that you upload and attach to your Question (or a Reply/Comment to it) using the green up-arrow in the Mapleprimes editor.

@janhardo If you want the direct input treated specially then you'll have to enter it in some special manner.

If you enter it as input in the usual manner then the bracketing is no longer present and recoverable once parsing is done to get an expression.

I have shown you a few possible special manners in which to input the expression. There are other possible syntax choices, including variants of those shown.

@mmcdara Numeric rootfinding -- like much other numeric computation -- involves a balance between functionality, robustness, and speed/memory performance.

Very often there is a give-and-take amongst these qualities, when comparing approaches. Ease of use (versus, say, the need to adjust options) is a related consideration.

Even for a restricted class of problem there will usually be some approach that is faster, and some which is more robust.

Even for the restricted class of problem of finding all real roots of a univariate polynomial this dichotomy arises. (Eg. some examples may be more ill-conditioned. Etc. High accuracy goals mixes in  too.)

The given problem class in this posting is more restricted still. You might find yet more specialized approaches. 

The fsolve command leans toward robustness and ease of use. In my experience NextZero leans toward speed. Comparing them sensibly should involve tightly specifying the problem class and goals.