@sand15 As an afterthought: I'm not sure I see why the triangulation isn't just lucky to not have any triangle that spanned across a key portion of the input region, and that when transformed would not (split and) hence not respect some concave aspect of the output region.

It that is so then I'm not sure that an algebraic analysis (and some kind of splitting) might not be needed in general, to accompany an approach of fill-by-triangles/polygons. Am I wrong? I often am.

While discussing alternatives, here's another quick alternative - possibly in said class of luckiness.

restart; with(plots): with(Optimization):
ineq1 := u^2+v^2<4: eq1:=u^2+4*v^2<=4: eq2:=(u+2)^2+2*v^2<=4*v:
(Eineq1,Eeq1,Eeq2) := subsop~(0=`=`,[ineq1,eq1,eq2])[]:
K := solve([Eineq1,Eeq2]): T1 := eval([u,v],K[1]): T2:=eval([u,v],K[2]):
Tumax:=Maximize(solve(Eeq2,u)[1],v=T1[2]..T2[2])[1]:
Tumin:=Minimize(solve(Eineq1,u)[2],v=T1[2]..T2[2])[1]:
display(shadebetween(solve(Eineq1,v)[1],solve(Eeq2,v)[2],u=Tumin..T2[1]),
        shadebetween(solve(Eeq2,v)[1],solve(Eeq2,v)[2],u=T2[1]..Tumax),
        shadebetween(solve(Eeq1,v)[1],solve(Eeq1,v)[2],u=-2..2),
        overrideoption,transparency=0,color="Niagara Azure",axes=boxed):
plottools:-transform((u,v)->[u^3-v^2,u^2-v^3])(%);

Also, in jest, one can even get lucky if plots:-inequal is called in a (here ad-hoc) special manner. (Naturally, this lacks the smoothest boundary since no boundary curves are constructed.)

restart; with(plots):
ineq1 := u^2+v^2<4: eq1:=u^2+4*v^2<=4: eq2:=(u+2)^2+2*v^2<=4*v:
F := plottools:-transform((u,v)->[u^3-v^2,u^2-v^3]):
copts := gridrefine=0,crossingrefine=20:
opts := optionsimplicit=[copts],nolines:
P2a := inequal(eq1, u=0-1e-6..2, v=-1..2, opts):
P2b := inequal(eq1, u=-2..0-1e-6, v=-1..2, opts):
P1a := inequal(And(ineq1, eq2), u=-2..-1/2, v=0..2, nolines,
              optionsimplicit=[grid=[7,29],copts]):
P1b := inequal(And(ineq1, eq2), u=-2..-1/2, v=0..2, nolines,
              optionsimplicit=[grid=[29,7],copts]):
display(F(P1a),F(P1b),F(P2a),F(P2b),axes=boxed);

@C_R It seems on-topic, then, to mention to your that the contents in the plotting substructure created by the (lowercase) typeset function call are not guarded against further evaluation.

That's also a consequence of the fact that plotting structures are just unevaluated function calls of (mostly) protected names. That's very old functionality.

In consequence, some differences may occur if such a plot gets further evaluated (by a top-level reference and full evaluation, being passed to a function call, etc).

Consider the following example, in which one wants the call sin(Pi/3) to be pretty-printed but not evaluated. Notice the accidental evaluation resulting in the unwanted sqrt(3)/2, and ways to avoid it.

I'm not going to bother to show the poor workaround of throwing extra unevaluation quotes (single right-ticks) around the expression.

(Inside a procedure, if name P were declared local, then referencing it after assignment would incur only 1-level evaluation -- with this problem not occuring.)

Download typeset_plot_eval.mw

These days there are alternative data structures that the system might better use for plotting. But too much code to change. It might be better if the plotting command preprocessed such (lowercase) typeset calls more robustly.

Is this 1D input or 2D Input? If the latter, is it in an Execution Group (red prompt), or a Document Block?

Does it happen only with your created palette's item(s), or any other stock item from a stock palette?

What happens when there is some expression both to the left and the right of the cursor?

It's probably worthwhile mentioning that there are other approaches than applying plottools:-transform to the a plot of the u-v region imposed by the implicit constraints.

For example, one might combine several filled parametric plots (or shadebetween calls), constructed directly using the transforming formulas for the 1st and second coordinates. However this may require sophisticated splitting/decomposition of the u- and v-domains into several manageable subdomains, based on the supplied inequalities. Not so hard for this example, but harder to generalize.

@sursumCorda I suspect that the best way to get smooth boundaries is to superimpose actual curves over whatever is used for filling the interior region (MESH, POLYGONS, GRID, whatever).

Below I construct such boundary curves and lay them over a DelaunayTriangulation (the idea for using such being due to member sand15).

Since I construct these boundary curves, I also have their data points for use in the triangulation. That's in contrast to sand15's approach of using the vertex data from the POLYGONS that plots:-inequal generates. Both approaches have pros & cons.

- triangulating POLYGONS data from plots:-inequal
  Pros:  the triangulating data is generated automatically.
  Cons: misses a chunk from botton corner for this example.
             boundary is ragged unless refinement is exorbitantly high
             or boundary curves constructed anyway.
             no visual distinction between strict and nonstrict inequalities
             is present, absent separate construction of boundary curves.

- triangulating data from computed boundary curves
  Pros: same curve data can be used for triangulating,
           for this example at least apparently more robust at cusps.
           the curves can optionally distinguish which boundary curves
           arise from strict inequalities.
  Cons: far less automatic (I think I could automate it, but it's not easy.)
            note: These curves are not adequately produced by plots:-inequal

The code below produced this plot, in about 0.68 seconds in my Maple 2022. For this I commented out the line that reassigns to PI the curve with linestyle=dot.

And here is the code with the optional visual cue of a dotted boundary curve to indicate the strict inequality.

I suspect that I could speed up the transformer for the polygons and make this faster. But programmatically automating construction of the boundary curves is more intriguing.

Download plot_transform_example1c.mw

@sand15 The idea of using DelaunayTriangulation is nice. Vote up for ingenuity.

I get the following image and timing of the computation, in my Maple 2022.2. (I corrected some missing statement terminators in the code you showed, but made no other significant changes.)

If I may make some constructive comemnts:
- The boundary is still somewhat rough. I still believe that this is cured better by superpositioning curves along the boundary than by refining the implicitplot options. [I am going to add such an attempt in another Answer thread.]
- There appears to be a chunk missing from the bottom-most tip of the transformed region.

Download plot_transform_sand15.mw

@FDS Note that the changes that I made to your Maple code make it more like what you showed for Mathcad: I made operator f take both p and i as parameters, and inside f it has Hb[i] and k[i] as indexed references.

For fun, here's another approach, this time dealing with the OP's first example.

restart; with(plots):
P := densityplot((u,v)->`if`(`or`(u^2 + 4*v^2 <= 4,
                                  `and`(u^2 + v^2 < 4,
                                        (u + 2)^2 + 2*v^2 <= 4*v)),0,1),
                 -2..2, -1..2, grid=[301,301], style=surface, labels=[u,v]):
P2 := subsindets(P,rtable,r->ImageTools:-Threshold(r,0.6,low=0.0)):
display(plottools:-transform((u,v)->[u^3-v^2,u^2-v^3])(P2),
        view=[-8.2..8.2,-4.2..4.2], axes=boxed);

I suppose that implicitplot could produce a boundary curve, which when transformed would give the boundary of the above a cleaner look.

note: The higher-than-default grid resolution puts a greater burden on the GUI's plot renderer. But the approach has the advantage of being simple. It also avoids some difficulty that thin-polygon-strip-fill approach can have when the region is not convex.

note. Other approaches are possible.

@Thomas Dean It works on (ubuntu) Linux, for me, using either Maple 2021.2 or 2022.2.

ps. You tagged your Question as Maple 2021.  Your latest Reply mentions Maple 2022.2. Which is it?

@Thomas Dean You mention having explicit multiplication symbols in the output. It sounds as if that is your primary motivation here.

In the following attachments I first set the GUI menubar item:
   Tools->Option->Display->Maple Notation

Then I executed the whole worksheet. That gave me line-printed expression output (with explicit multiplication symbols) and properly rendered plots.

That worked for me in either Maple 2021.2 or Maple 2022.2, both for Linux.

plot-problem_ac_M2021.2.mw
plot-problem_ac_M2022.2.mw

I left other items as their defaults, ie:
 -- Maple 2021.2  interface(typesetting) returns standard
                            interface(prettyprint) returns 3
 -- Maple 2022.2  interface(typesetting) returns extended
                            interface(prettyprint) returns 3

@Thomas Dean It's not clear to me whether you want 1D output or 2D (typeset) output.

@sursumCorda For your first example plots:-inequal is generating many small (thin, say) POLYGONS substructures that when rendered together give the appearance of a filled region with curved boundary.

The transformation of those looks almost useful, something somewhat like what was desired. The scrappy end result is of mixed usefulness.

But in the second example plots:-inequal produces the POLYGONS substructure required only to render the triangular domain. That gets its (few) vertices transformed to something which lacks the information about how the triangle's boundary curve and interior region would (ideally) get transformed.

In contrast, the plot3d command that I used generates a surface whose interior points are represented explicitly in a MESH substructre. That gets transformed to another 2-D MESH substructure that retains information about the interior point's transformation, and which gets rendered quite nicely as a 2-D region. It's transformed edges are a little ragged, so I added spacecurves (which also contain many explicit data of points) along the boundary lines, so that after transformation the final result's boundary consists of smoother boundaries.

@Thomas Dean I did not notice that detail before. But good to know, thanks.

Do the Examples on the Help page VolumeOfRevolution show properly? I mean, when you open the Help page but without re-executing the examples?

note. Your posted code runs fine for me, showing a plot, using Maple 2021.2 on a similar ubuntu system.

@Thomas Dean Perhaps it's happening because you are using a version of an Operating System which is not officially supported for your Maple version? (See here, for a list for Maple 2021.) Or perhaps some Java adjustment is needed, for some kind of inline 3d plotting of the Java GUI on your system.

@mmcdara I converted it from a Question to a Post, because it didn't contain a question.