Some mathematical functions and also some (not so) inert functions are implemented as objects.
For example, Perm is used to represent permutations.

p :=Perm([2,3,1,5,4]);  # ==> disjoint cycles representation
        p:=(1,2,3)(4,5);
lprint(p);
Perm([[1, 2, 3], [4, 5]])
    
Perm acts as an inert function (like RootOf) but it's an object.
Is it possible to convert it into a true inert form such as PERM([[1, 2, 3], [4, 5]]) and so, being able to extract the arguments with op?  

In this specific case we may use
convert(p, disjcyc);
       [[1, 2, 3], [4, 5]]
    
but this is possible only because Perm has a convert export.
So, is it possible to obtain the arguments directly (without convert)?
This would be useful for other situations.

If I copy the output of a lprint command e.g.
lprint(<1,2;3,4>);

Matrix(2,2,{(1, 1) = 1, (1, 2) = 2, (2, 1) = 3, (2, 2) = 4},datatype = anything
,storage = rectangular,order = Fortran_order,shape = [])

and paste it in a new execution group, I obtain a "Line print output" instead of a Maple (1D) input,
so it cannot be executed.
(Of course, it's possible to paste in Notepad to remove the format, but it's annoying.)

This happens in Maple 2019,  Windows 64, Worksheet mode, 1D input;  but not all the time (sometimes it is as it used to be).
Do you see the same behavior?

If f is a procedure e.g.  f := x -> x^2;  then f[a](b)  evaluates to f(b)  (= b^2).
Do you know where is this feature documented?
(I have used this in the past, but I need now a reference and I cannot find it).

1/0;
Error, numeric exception: division by zero
lastexception;
            0, "numeric exception: division by zero"
lastexception; # ???
            Typesetting:-Typeset, "invalid input: %1 expects %2 arguments, but received %3", type, 2, 3

So, printing lastexception produces a new error!
When typesetting=standard, it's OK.

L:=[1,2,0,4]:
s := sum(1/L[i], i=1..nops(L));

Error, (in limit/mrv/limsimpl) too many levels of recursion

So, this error cannot be caught by try

try    # bug
  s := sum(1/L[i], i=1..nops(L));
  catch:  s:=infinity
end try;

Error, (in limit/mrv/limsimpl) too many levels of recursion

Strangely, for L:=[1, 2, 0.0, 4]  it's OK.

Everything works with add instead of sum, but this is another thing.