The procedure shown as IPP:-Convolution is a local member of the IPP submodule of the SignalProcessing module (package).

Here are two ways that you can inspect its (initial) form.

restart;
showstat((SignalProcessing::IPP)::Convolution);

Convolution := proc()
   1   passign(procname,defun(convert("Convolution",'string'),"msp",(':-mtsafe
         ') = true));
   2   procname(_passed)
end proc

restart;
kernelopts(opaquemodules=false):
eval(SignalProcessing:-IPP:-Convolution);
kernelopts(opaquemodules=true):

proc()
   option THREAD_SAFE;
   passign(procname, defun(convert("Convolution", 'string'), "msp", ':-mtsafe' = true)); procname(args)
end proc

That somewhat obscure-looking code serves the purpose of rewriting the procedure's own body the first time it gets called.

SignalProcessing:-Convolution(Array([5,7]),Array([-2,6,10])):

kernelopts(opaquemodules=false):
eval(SignalProcessing:-IPP:-Convolution);
kernelopts(opaquemodules=true):

proc()
   options call_external,
           define_external(mspConvolution, MAPLE, LIB = "libmsp.so", THREAD_SAFE);
   call_external(0, 140184961382080, true, true, args)
end proc

The first time it gets called it sets itself up and replaces itself with a so-called external-call, ie. a call out to a precompiled external dynamic library. In this case it is an external-call to a bridging function, and the module name IPP suggests that the bridge is to a suitable function from the Intel IPP Library (Integrated Performance Primitives), containing highly optimized functionality that includes signal processing.

Your attachment doesn't provide your own method for shading under the curve, even for any fixed T value. You said you knew how to combine that with the curve using plots:-display, but didn't provide any example of just what you meant. So I'll supply something crude for that part of the task.

Here are a few ways. One of them calls densityplot dynamically, for each new "explored" value. The other computes a sole densityplot up front, and then transforms that to fit under your curve.

Also the first uses WavelengthToColor from the ColorTools package, while the second uses a linear hue gradient (which is of course not quite right). You may have your own wavelength->hue method. I am not satisfied with the values from WavelengthToColor, but I am having trouble finding my own version written many years ago...

You can experiment with various combinations, to see which gets you the smoothest action under a continuous movement of the Slider. If the code is too slow to compute each frame (for each T value) then continuously moving the Slider will produce a computational backlog and make the action appear jilted. In such a case you could toggle off continuous-updating of the Slider, having it only compute once, after the Slider is finished its move. But a continuous update is more visually impressive, if the frame computations are fast enough to allow it.

You could mix and match the apporaches: transformation of a single precomputed densityplot, or dynamically generated densityplots -- either of those using any wavelength->hue scheme mentioned above, or your own.

You could also call Explore directly on some of the plots:-display calls, without need for name procedures (foo, blah). I prefer such custom procedures because then I can test them by calling them outside of Explore.

Download Planck_curve_ac.mw

It is also possible to use the full qualities of the colors, ie. also use their intensity and saturation, and not only their hue (with maximal intensity and saturation). Perhaps its prudent to wait for complete details of what you want to accomplish, and what you want the colors to represent in terms of power or perception.

My Maple GUI sometimes gets into this state.

If I shutdown the GUI (either using the menu, or the corner Close icon) then it (almost always) prompts me whether I want to save the open worksheet. If the worksheet was not yet saved as a filename then usually it prompts me for a filename at that point.

If that works then I can Relaunch the GUI and then Reopen the saved worksheet.

A rare scenario is that it gets into the problem state but doesn't allow me to save. Hopefully that is not your case.

Here are various ways.

Obtaining floating-point approximations is relatively easy, and two direct ways are shown, ie. straight calls to a single command. The fsolve example relies on guessing an overestimate of the number of roots. The Calculus1:-Roots example doesn't require such as guess.

Obtaining all the roots in 0..2*Pi, in exact form, is also shown, in a few ways that have varying success and complexity. These kinds of computation can involve using fortuitous simplifications -- sometimes both before and after substitution. (Discovering a sufficient simplification is one aspect that can make this tough, for both the user and Maple's own symbolic solvers.)

Download solve_trig_ex.mw

[edit] The above was done in Maple 2021.1. In my older Maple 2019.2 getting the nicer exact form of (some of) the results from the second calls to Calculus1:-Roots required a slightly different simplifying concoction, eg.
    simplify(evala(simplify(convert(ans2b,expln))))
solve_trig_ex_2019.2.mw

I will submit some of these weaknesses in simplify as bug reports.

The Units:-UseUnit command allows you to set the units to which something (of the matching dimension) will simplify. But I don't see that as also providing the given choice via the right-click units-formatting menu, in my Maple 2021.1.

But I do get that choice -- via the right-click menu -- if I use an older mechanism involving two commands, Units:-AddSystem and Units:-UseSystem.

In the attached worksheet I utilized the right-click units-formatting on the last line's output, and selected the desired choice from the drop-menu. Only that last output has right-click units-formatting.

Download UseSystem_units_formatting.mw

Already in Maple 2016.0.

kernelopts(version);
              Maple 2016.0, X86 64 LINUX, Feb 16 2016, Build ID 1113130

f := x*y:                                           

JH := int(Heaviside(f-1/2), x=0..1, y=0..1);        

         JH := 1/2 - 1/2 ln(2)

JP := int(piecewise(x*y>1/2, 1, 0), x=0..1, y=0..1);

         JP := 1/2 - 1/2 ln(2)

Your example of 1.0*e7 is rather simple, and there are many trivial ways to render 10e6 based on 1.0e7 as input. Something more general could be useful.

I looked around some old worksheets and found the following for engineering notation of floats.

(The finesse of stripping trailing zeros -- one of several options below -- is based on a revision on some old code by Axel Vogt.)

In custom axis-tickmarks of the second and third plots below I show some additional formatting choices (which you could also use in formatting other float values for the legend).

restart;
EN := module() local ModuleApply, Strip;
  ModuleApply := proc(t::numeric,
                      {displayonly::truefalse:=true,
                       enotation::{truefalse,
                                   identical(lowercase)}:=false,
                       showzeroexponent::truefalse:=true,
                       stripzeroes::truefalse:=true})
    local m,mant,sgn,strip; uses InertForm;
    strip := `if`(stripzeroes,Strip,x->x);
    if t=0.0 then (m,mant,sgn) := 0,Strip(t),1;
    else m := iquo(ilog10(t),3);
      (mant,sgn) := Strip(10^(-3*m)*t),signum(t);
    end if;
    if showzeroexponent=false and m=0 then Strip(t);
    elif displayonly then
      if member(enotation,[true,':-lowercase']) then
        nprintf("#mrow(mn(%a),mn(%s),mn(%a));",
                `if`(mant=0.,"0.",
                     sprintf(sprintf("%s.%af","%",
                             length(op(1,mant/sgn))-ilog10(mant/sgn)-1),
                             mant)),
                `if`(enotation=true,"E","e"),3*m);
      else sgn*Display(mant/sgn%*10%^(3*m),':-inert'=false);
      end if;
    else mant*10%^(3*m);
    end if;  
  end proc:
  Strip:=proc(x)
    local M,E,sM,smu,res; uses StringTools;
    if x=0 then return x;
    elif not type(x,float) then return x;
    elif x < 0 then return -procname(-x) end if;
    (M,E) := SFloatMantissa(x),SFloatExponent(x);
    sM := convert(M,string);
    smu := SubstituteAll(TrimRight(SubstituteAll(sM,"0"," "))," ","0");
    res := SFloat(parse(smu),E+length(sM)-length(smu));
    if res=trunc(res) then trunc(res) else res; end if;
  end proc;
end module:

Lres := 1/((2*Pi*freq)^2*Cres):
ftest := 10e6:

plot(eval(Lres, freq = ftest), Cres = 0.0 .. 1e-9,
     labels = [Cres, 'Lres'],
     legend = EN(ftest),
     color = red,
     title = 'Inductance*Value*as*a*Function*of*Resonant*Capacitance',
     axis = [gridlines = [default]], size=[600,300]);

plot(eval(Lres, freq = ftest), Cres = 0.0 .. 1e-9,
     labels = [Cres, 'Lres'],
     legend = EN(ftest),
     color = red,
     title = 'Inductance*Value*as*a*Function*of*Resonant*Capacitance',
     xtickmarks = map(x->x=EN(x,enotation=lowercase),[seq(0.0..1e-9, 2e-10)]),
     axis = [gridlines = [default]], size=[600,300]);

plot(eval(Lres, freq = ftest), Cres = 0.0 .. 1e-9,
     labels = [Cres, 'Lres'],
     legend = EN(ftest),
     color = red,
     title = 'Inductance*Value*as*a*Function*of*Resonant*Capacitance',
     xtickmarks = map(x->x=EN(x,enotation=lowercase,showzeroexponent=false),[seq(0.0..1e-9, 2e-10)]),
     ytickmarks = map(x->x=EN(x,enotation=lowercase,showzeroexponent=false),[seq(0.0..1e-5, 1e-6)]),
     axis = [gridlines = [default]], size=[600,300]);

engineering_notation.mw

The attached worksheet contains a few more corner cases (testing), and a column-by-column table for visually easier comparision of optional effects.

There is room for improvement. When stripzeroes=false is specified then additional trailing zeroes appear -- so at present it can't be used to denote the concept of precision or extra significant-figures.

There are several pitfalls, where the regular typesetting mechanisms can interfere and undo part of some crafted solutions. But at least all this doesn't involve the poor mechanism of applying ``(...) and the ensuing italic font and unnecessary brackets.

You might play around with the colorscheme used in a densityplot of the complex argument of the function.

Download cplx_plot_colorscheme.mw

Another way to obtain the color image of that second example (the full hue range) is to rip the color substructure out of the complexplot3d result. This allow you to display it as an image instead of as a high resolution density plot, and so place much less burden on the GUI interface. (You may find that the GUI becomes slugglish when scrolling or saving, for the other approaches in this Answer which render plots.) Eg,

restart;
f := x -> x^3 + 3^x:
H:=op([1,4,2],plots:-complexplot3d(f,-17-35*I..23+35*I,grid=[700,400])):
hsv:=Array(1..700,1..400,1..3,1.0,datatype=float[8]):
hsv[..,..,1]:=360*H:
img:=ImageTools:-Rotate(ImageTools:-HSVtoRGB(hsv),90,':-degrees'):
plot(view=[-17..23,-35..35],background=img,
     labels=[Re(x),Im(x)],
     size=[700,400]);
ImageTools:-Embed(img);

note: The background option to the plotting command is a little buggy (offset) in (only, so far) release Maple 2021.1.

Yet another way to do it as a density plot is to transform the complexplot3d result from 3D to 2D. This is an easy way to avoid some of the artefacts (due to undefined, say) in the earlier full hue densityplot result. Eg,

restart;
f := x -> x^3 + 3^x:
Q:=plots:-complexplot3d(f,-17-35*I..23+35*I,grid=[700,400],
                        style=surface,size=[700,400]):
plottools:-transform((x,y,z)->[x,y])(Q);

[edit] Your Question's title contains the wording, "...2D line type separating the real and imaginary parts". But I have considered reproducing the kind of plot colorings that you showed in your Question. If you really want to show only some curves/areas where the complex argument takes on only some finite number of values (or within epsilon of such) -- such as when the result is purely real -- then please respond and be very clear and explicit about the goal.

For your first example, try,

   fsolve(f(x)=g(x))

For your second example, try,

   plot( [ Re(f(x)), Im(f(x)) ] )

f:=x->(x^2)-6*x+p+3: g:=x->(4*x^2)-(p-8)*x+7:

sol:=solve({ f(xf)=g(xg), D(f)(xf)=0, D(g)(xg)=0,
             (D@@2)(f)(xf)>0, (D@@2)(g)(xg)>0 });

     /                      -5\    /                     1\ 
    { p = -12, xf = 3, xg = -- }, { p = 12, xf = 3, xg = - }
     \                      2 /    \                     2/ 

eval({f(xf),g(xg)},sol[1])[];

            -18

eval({f(xf),g(xg)},sol[2])[];

              6

Maple's model of functional evaluation is inside-to-outside, and if you want to avoid some potential evaluation issues then I suggest reducing the inert operators from the inside out.

Here's an example, (based in part on this old code's idea). The inert=false option merely allows the output to render in the usual way, as opposed to the gray glyphs.

Download inert_value_recur_outwards1.mw

If you really want you can get the behaviour from the outside in, but something general has to be given up. You won't be able to use the inert form of every command (eg. fsolve), while retaining evaluation at each step. But if you're willing to allow inert forms of, say, just arithmetic operators and some simple things (that can return unevaluated) then something could be accomplished with recursion & state (operand list for position, and running expression) & subsop.

Note that the construction of 2^(2/3)/2 from input 2^(-1/3) happens as a consequence of automatic simplification.

As such it cannot be prevented by delaying evaluation, eg. by use of uneval quotes, etc.

You may be able to use the inert operators such as %^, etc, to construct something that can be displayed as you want.

Download inert_ex.mw

At this point you may care to inform us of how the expression is first formed, ie. do you want to type it in, or is it a result of a computation.

If I understand the question properly, here are some alternatives you might consider.

The first one changes only how it gets normally pretty-printed. The second actually strips off the outer call.

You only have to define the procedure once per session, and you don't have to do some extra step each time you want to create or print an inert expression.

Download inert_plus_single.mw

You might also do something similar for `%*`.

The integervariables option of the LPSolve command allows you to specify (as a list) the names of the variables which must be integer-valued.

Eg,

with(Optimization):

obj := -4*x-5*y:

cons := {x+3/2*y<=6, 5*x+4*y<=20, x>=0, y>=0}:

LPSolve(obj, cons,integervariables=[x]);

   [-20.666666666666668, [x = 1, y = 3.3333333333333335]]


LPSolve(obj, cons, integervariables=[y]);

          [-21.0, [x = 1.4999999999999998, y = 3]]

LPSolve(obj, cons, integervariables=[x,y]);

                 [-20, [x = 0, y = 4]]

Your original attachment called implicitplot for first argument M (which implies M=0), and it called contourplot on first argument M with option contours=[1] (which implies M=1). That's a mismatch in the values/heights of the contours/level-curves, which makes the comparison invalid, and which I've corrected below.

Below are plots for M=1 and M=0, each done with both those commands for comparison.

I used a larger initial grid option size, for implicitplot, and bumped down the gridrefine option's value.

The results basically match, between implicitplot and contourplot, except the latter's curves are coarser. The former is much faster and smoother. And the latter produces a coarser result even with a large grid value, that consists of a very large plotting structure that places considerable burden on the GUI.

Here is a revision, done in Maple2016.2,

SDFFM_STAB_ac.mw

With your original grid=[5,5], gridrefine=8 some features/regions get missed. (Missed, I suspect, during initial analysis at the unfortunately-coarse initial [5,5], and hence subsequently also missed for refinement.)

In Maple 2021.1, by the way, the implicitplot command has some trouble with the very large (+/-) values of M, or with the severe slope, I suspect. That can be accomodated by an adjustment, to pass it, say,
    max(min(M,2),-2) = 1
instead of just M=1. And similarly for M=0.

SDFFM_STAB_ac_2021.1.mw