@Carl Love 

You wrote, "It is obvious that the proper evaluation of F(G(e1, e2)) assuming a1, a2 requires that the assumptions be applied before F(G(e1, e2)) is evaluated."  But that aspect that you describe as obvious seems to be crux of what surprised the OP -- ie. the fact that all instances of name `x` within the unevaluated expression are temporarily replaced with an assumed name, prior to any part of F(G(e1,e2)) being evaluated. Hence the replacement with assumed names happens before even G(e1,e2) is computed.

That is the ususal evaluation model of `assuming`. It is (IMO) conveyed by the first sentence in the Desciption of the Help page for that command. The entirety of the first argument is evaluated under the assumptions placed on the names present.

@Kitonum Yes, but regardless of the strength of `solve`, isn't it zero over that wider domain?

I don't see why examination of the domains of subexpressions (radicals, csgn, ln, etc) present in some *particular* representation should always be an adequate and correct methodology. Their individual imaginary contributions may cancel for some x. Just because we don't know how to simplify/manipulate the expression into a representation where it clarifies differently doesnt mean that the expression might not be real-valued on a larger domain.

@Kitonum Why should one care that some arbitrary part of the expression may be considered as nonreal, as long as the whole expression is zero?

@Kitonum Perhaps I am missing something.

Why not   -exp(2)-1<x, x<=exp(2)-1  ?

(I don't mean just what solve returns.)

@snowman I just threw that in so that the procedure FF would return unevaluated if called with an argument that was not a number (eg. a name). That allows you to pass around FF(r), with r an unassigned name. It is not necessary here since the procedure returned by Interpolate (and assigned to F) already behaves like that. But when I started writing I didn't know for sure that I'd stick with the Interpolate approach.

The same mostly goes for that try...catch. I didn't know whether I'd need it, and I was suppressing potential difficulties.

Here is a copy of that worksheet which uses just F, and omits FF as wrapper. It works as well.
   polar_densityplot_modif.mw

Btw, I notice a slightly more even color gradient (visually more even, to my eye, at least) if I make the colorscheme progress through the Luv color space rather than the default. Another possibility is to adjust the grid resolution. Your opinion might differ. Eg,

plots:-densityplot(F(r), r=0..1, theta=0..2*Pi,
                   style=surface, axiscoordinates=polar,
                   labels=["", ""], grid=[101,51],
                   colorscheme=["zgradient",["White","Red"],
                                colorspace="Luv"]);

@Kitonum And for,

   simplify(expand(convert(Expr,exp)));

?

Sorry, you may have missed my interim edit, while responding. [edit] I updated it slightly before you posted your response. You might well have been submitting in the brief interim.

@snowman I did not understand before that you meant that f(r,theta) was independent of theta, sorry.

But I don't understand whether the numbers are supposed to relate to your given image. The data has r from 0..1, and f(r,theta) from 0.0..2.9. But your image shows x and y from -200..200 and values from 0.0..0.6.

Are the data and your image directly related? Or is the given image simply an example of a density plot with polar symmetry, but with values otherwise unrelated to your data?

I am going to suppose that the image is merely an example, since for one thing it is not independent of polar angle.

@nm I wrote that the (inner) call to odetest produces zero under the assumption. You have now left out the assumption, which is contrary to what I suggested.

That is the whole point of my answer. You have left out the key part of my answer.

In your first example,
   simplify(odetest(mysol,ode)) assuming x>0
invokes odetest under that assumption.

In your second example you were not calling odetest under the assumption.

That is the difference.

You quoted a sentence out of context. Here are the first two sentences in my Answer:

   "In the first case you are also calling odetest (and not just simplify)
    under the assumption.

    And that produces zero (in my Maple 2020.1 at least) even
    before simplify is called."

The "that" in the second sentence refers to the act (from the first sentence) of calling odetest under the assumption. You quoted the second sentence, ignored the first sentence and the context of "that", and then showed yet another call to odetest without the assumption.

There is nothing strange at all that the whole of the nested call is done under the assumption. This situation is neither uncommon not mysterious.

[edit] These examples are straightforward and normal instances of use of the assuming command, and follow its documentated description.

Please supply the more complete data:

      [r, theta, f(r,theta)]

for each (r,theta) pair.

If not, then it's pretty difficult to accomplish without knowing the f mapping.

@Bland3 I apologize for not being clear before.

I had written to someone about size formatting in pretty-printed subscripting by email, not in this forum. I apologize, as I see now that I gave the wrong impression.

I meant also that I have done several things like this and this old answer, but in greater detail and with some more programmatic flexibility. (The search facilities are so bad on this site, that I too have great difficulty finding some of the other related procedures I've posted on this site for very similar tasks.)

I would like to study your worksheets and requirements and use come up with a decent answer that is programmatically usable. I am just very busy right now.

I would also like to put together the kind of general description and example sheet that you suggest. But I don't know just when I'll have a next opportunity.

@Bland3 I am guessing that one of your requirements is the ability to have the nested sucscripting show with descreasing font sizes. (Coincidentally, I had just showed a method for that to someone else two days ago.)

I have written procedures that allow programmatic control over typesetting expressions (and even mixed math and text). I have done that in Answers in this forum, from scratch, a few times, as has Carl Love. Rather than duplicate the efforts from scratch, it might suffices to find some of the best prior responses, merge, and utilize to handle your own example(s). It'll take me a whirl, to locate and sift through.

Automatically decreasing font size for subscript-nesting might be new, though.

Yes, it is possible to do typesetting (within plots, or just as 2D Output) where there is control over the font size and color directly within the expressions and plotting "labels" themselves. (I'm not talking here about any new LaTeX importer, naturally.)  I'll try to come back to this soon, but busy right now...

@Carl Love Perhaps PDF export could be made to work. I don't really know enough to say.

But, even with some warts, I'd still like to get back the old inlining, and have that be the top priority. I especially liked that 1D input lines could be copied properly.

@Carl Love I'm going to try and ping the admins by email, about the worksheet inlining issue. I agree, it is very important to this forum.

My limited understanding is that this site uses (or did use) MapleNet technology for rendering worksheets. I believe that for a long time it was stuck back at an old version of that technology.

I know that there has been improvement to how the Maple Cloud renders worksheets. I would like to see an investment of development in improving this forum, including not only fixing worksheet inlining but improving it also.

I agree with you, that hearing different points of view on topics like this Question can help understanding. I'm glad you answered.

@Carl Love Yes, your examples and explanation reproduces most of what I had in my attachments and comments.

There is one minor wrinkle which your posted code does not account for, directly. The OP's goal is to call his ValveLaminarMassFlow_proc once more, at the computed root, and take the second value from its return value (of an expression sequence). His original choice was to make f an easy mechanism to get that value too. Hence my followup suggestion (in which like you I too had made f return unevaluated using 'procname' when x was not of type numeric) to allow f to accept the index as second argument. And I had it return both arguments in the unevaluated 'procname' call, to preserve the call appropriately.

There is one more wrinkle which I avoided describing in detail. The problem with premature evaluation of the call f(x) (within the original f(x)[1]=x argument passed to fsolve) can usually also be accomodated using uneval quotes. That works in the OP's worksheet if Units:-Simple is not loaded, but does not work directly if it is loaded. I didn't think that it would be to the OP's great benefit to discuss that problem variant in gory detail.