You need to be able to distiguish the free variable eps (which could even be an expression) from the variable r, which must be a variable because it'll temporarily be bound by int before being returned free (free and bound are opposites). There is no "clean" way to do this without passing r to f. By "clean", I mean without subverting the normal evaluation rules and without globally designating r as the temporarily bound variable. So, I'd do this:

f:= (g, r::name)-> int(g(r), r):

Then you could achieve your two desired calls as 

f(h, r);
f(h@(x-> x+eps), r);

This works whether g or h are defined procedures, just names, or some concoction in between those two. The shift function x-> x+eps could be predefined:

sh:= eps-> x-> x+eps:
f(h@sh(eps), r);

I recommend that you never use the syntax f(...):= ... to define a procedure (sometimes called a "function", but that word is ambiguous when talking about Maple). That syntax works sometimes, but not always.
 

If you want some numbers to be ignored, make them names rather than strings. You can do this by replacing "2222" with `2222` and likewise for the other string.

Thus, I get

By the way, your entire for loop can be replaced by map[inplace](evalf@log[10], B).

I agree that that is a bug. I've seen it many times before. It seems to be related to large fractional exponents. They cause solve to create RootOf expressions of polynomial degree the numerator of the fraction. So, in this case, that's a polynomial of degree 131537.

A workaround is to convert the exponent to a symbol:

Eq:= 1 - 1/(1+203808*exp(-342569/506*t)*(1/131537))^(131537/203808) =
44983/56599;
Eq2:= evalindets(
   Eq, anything^fraction, e-> op(1,e)^convert(op(2,e), name)
);
sol:= {solve}(Eq2, t);
evalindets(sol, name, parse);
evalf(%);

Acer's Answer overrideoption is the best way to do this. I just want to show you a primitive alternative to your primitive method.

#Your way:
c  := op(select(has, op(1, b1), COLOUR));
b2 := eval(b1, c=COLOUR(RGB, 1, 0, 0)):

#Replace with:
b2:= evalindets(b1, specfunc(COLOUR), c-> COLOUR(RGB, 1, 0, 0));

I mention this because, IMO, evalindets is the most important command in all of computer algebra and everyone should learn it.

My code does not necessarily do exactly the same thing as yours. Mine replaces all colors.

The conversion of an expression sequence to a list and vice versa is a triviality both in terms of coding and efficiency. Kitonum has shown the coding syntax. Regarding the efficiency, both the time and memory needed for the conversions are very small constants; they do not depend on the length of the data.

It is often better to stick with lists because of the indexing problems that can occur when an expression sequence has 0 or 1 elements.

This should not have been a separate Question, but since Tom already put an Answer here, I won't delete it.

To me, the input diff(x-1 = 0, x) is not GI (garbage input) nor is 1=0 GO (garbage output). As I was trying to explain in the other thread, everything makes sense if you take into account the quantifications that are implicitly present.

Maple allows for the simultaneous differentiation of both sides of an equation, and this is often useful. However, you could argue that this shouldn't be allowed (because of this very problem). And thus you could argue that diff(a = b, x) should be considered GI and an error for any a and b. If this restriction were to be imposed, I wouldn't object. It's trivial to use overload to impose that restriction:

restart:
diff_orig:= eval(diff):
unprotect(diff):
diff:= overload([
    proc(e::`=`)
    option overload; 
        error "Differentiation of equations not allowed."
    end proc, 
    diff_orig
]):
protect(diff, diff_orig):

The output 1=0 could be viewed as an algebraic equation or as a boolean relation. If it's an equation, then it's an equation whose solution set is empty. That's not garbage. If it's a relation, then it evaluates to false; false is not garbage.

The input and output considered together constitute a proof-by-contradiction that there does not exist any differentiable function f such that f(x) = x - 1 and f(x) = 0 (for all x in whatever domain of differentiation you want to consider). That's knowledge (albeit trivial), and knowledge isn't garbage.

You could do it in the way that you suggest if you want, but all the standard differential operators are in the VectorCalculus package: Gradient, Jacobian, Hessian, and several others.

As a workaround, you can do this:

with(Physics):
Physics:-Setup(assumingusesAssume= false):
csgn(a - b[2]) assuming a > b[2];

The simplify and all the other assumptions are superfluous. You can put them if you want, but they make no difference.

The number of combinations that you're trying to generate is so large that they could not be listed by any computer (or any other method), ever. And it's not possible that there ever will exist a computer (or any other method) of doing this. We can count the number of such combinations like this:

Number(Iterator:-MultiCombination([2^16 $ 2^8], 2^16));
7820701318841130906613553459164687216584467046464667050034224507
  41484858519585179827709391651098624501404918769795637653274401
  57029711677787977640862663017116097938315215722518761350936266
  38516727105642689147056759932239793313894413127816886156554817
  76804366751588302164524267450481108817377756113734373353127476
  60436555681987839580644837879373377115558668241858194605420318
  57090864326621621084868745055201958236210246318706997513184396
  62089540815829177821487234240936427010441020860670200642172134
  59286677922608980438360909995794377076419365877451789293653200
  24753539064997228881393914518695160243181091267722013448011707
  00847339475028997519306136404337673374805865549565962012504690
  7222757907787394934267401909783755764225

evalf(%);
                                     723
                       7.820701319 10   

So, if every cubic meter in the entire Universe contained a computer, and they each generated one combination each nanosecond over the entire age of the Universe, then the progress they would've made on the job would still be far less than the progress made on the job of counting every atom in the Universe by counting a single atom.

So, you need to say what you want to accomplish by generating these and figure out a way to do it without generating them.

The way that you're using indexing (numbers appearing in square brackets appended to expressions) makes no sense to me, and the error message implies that it makes no sense to pdsolve either. I have no idea whether pdsolve will ultimately be able to solve your problem, but at this point it doesn't even recognize the problem as a PDE.

Suggestions:

1. Don't use 2D input.
2. Make your primary goal to get pdsolve to recognize your system as a PDE without error. Having the system prettyprinted on screen in a certain way should only be a distant secondary goal.
3. Don't use PDEtools:-declare because its purpose is primarily to address cosmetic rather than syntactic issues.
4. If you want 2 us (or any other variable), just call them u0 and u1. 
5. Stop saying that you want to solve it by the perturbation method (or any other method). If you can't even input the problem, then the method chosen to solve it is at the moment irrelevant.

The cosmetic issues can be addressed afterwards. They are of course irrelevant if it can't even recognize what you've entered as a PDE.

By design, the command subs does not do any type of mathematical manipulation. The things appearing on the left sides of the substitutions must explicitly appear in the expression being changed. Understanding the mathematical relationship between exp(a) and exp(-a) is something that subs does not do (by design).

"Convert floats to rationals" means to convert any numbers with decimal points (aka "floats") into exact integers or fractions expressed as a ratio of integers (aka "rationals"). The command convert(..., rational) will do this. You can apply this command to the entire system of equations at once; there's no need to treat each number individually.

You are using the word "order" where I think you mean degree. Yes, it's true that your equations (after being reduced to polynomials) are degree 3. In the univariate case, that would mean 3 solutions per equation (counting possible multiplicities and solutions that must be discarded because they lead to 0 denominators). The multivariate case is more difficult to count. Without regard to your specifc equations, all that we can say is that the maximum number of solutions of a system of 2 degree-3 equations is 3*3 = 9.

Here's how to convert your system to rationals:

eq_VS_m4:= 132.790562 = -0.000588*VRi + 0.995381*VRr - 
    (1692.955600*VRi - 1747.964480*VRr)/(VRi^2 + VRr^2):
eq_VS_m5:= 0 = 0.000588*VRr + 0.995381*VRi + 
    (1747.964480*VRi + 1692.955600*VRr)/(VRi^2 + VRr^2):
Sys:= convert({eq_VS_m||(4..5)}, rational, exact);

The exact is optional.

And here is how the system can be reduced to a single quadratic:

Se:= eliminate(Sys, VRr);
      [ /        
Se := [{ VRr = - 
      [ \        

                               1                                      
  ------------------------------------------------------------ (4 VRi 
  33953752813744399363729225 VRi + 435026389377170333527426880        

  (8764251389865934151895845 VRi + 112422402706002345584760664))

  \    /                                2
   }, { 4367704732338974625213889705 VRi 
  /    \                                 

   + 111644550712064136430569347176 VRi

                                   \ ]
   + 713443278578559346984980083200 }]
                                   / ]

I chose to "eliminate" the variable VRr. In this particular case, I could just as well have eliminated VRi; however, it's not always that easy to switch. (Indeed, deciding on the order with which to eliminate variables is a major computational issue in computer algebra.) The result of eliminate is a list of two sets. The first set is equation(s) (just one equation here) solved for the variable(s) that you wanted to eliminate. The second set is expression(s) (assumed to be equated to 0) that remain to be solved. In this case, we see that the remaining equation is quadratic.

The Answers by Kitonum and Oliver are correct. I'd just like to provide an Answer with more theoretical context. And I realize that you realize that what you posted is more-or-less an anomaly rather than a bug. There is however a very broad CAS design issue that could be addressed.

I'll assume that you're at least somewhat familiar with the two main^[*1] quantifiers of formal logic (although you may not have realized that these concepts had such formality). Their formal names are "the universal quantifier" and "the existential quantifier". There are a vast number of ways that these can be phrased in common language; the most-generic phrasings are "for every" or "for all" for the universal and "there exists" for the existential. In symbols, the universal usually appears as an upside-down uppercase A, and the existential as a mirror-imaged uppercase E. Quantifiers are used to bind^[*2] variables to propositions (statements whose truth can be evaluated once their variables, if any, have been evaluated).

The problem with Maple (and it's also a problem in many CASs) is that variables are too often allowed to be free^[*2] when they should be bound^[*2].

Now let's consider your situation starting with your equation x+y = 1 in some different contexts (i.e., with some different variable bindings (the plural gerund of bind)). 

1. In its most-usual algebraic context, this equation could be more formally stated as "There exists a pair (x,y) such that x+y = 1" and even more formally as "There exists a pair (x,y) in A x B such that x + y = 1" (where A and B are some specified sets such that the proposition is sensical and A x B means the Cartesian product).
2. ​​​​​​In the context that you use the equation, it could be more formally stated "There exists a y in some domain D over which differentiation is defined such that for all x in D, x+y = 1."
3. (Oliver's context) "There exists a function (or multi-function) y defined over some domain D over which differentiation is defined such that for all x in D, x+y(x) = 1."

So, these are mathematically different statements. In the context that you used, (2), obtaining 1 = 0 is not a paradoxical contradiction. Rather, it's a proof-by-contradiction contradiction that proves that there does not exist such a y.

[*1] Each of these quantifiers can be expressed in terms of the other.

[*2] The past participle of the verb bind is bound (e.g., "Variable x is bound in the expression int(f(x), x= a..b)."). The opposite of this usage of bound is the adjective free. This usage of bound mustn't be confused with the noun bound and its associated past participle bounded (e.g., "The upper bound of x in int(f(x), x= a..b) is b; x is bounded by a and b."). This can be quite tricky because, as the example sentences show, the two distinct mathematical meanings of bound can appear in identical contexts.

By default, Maple's Dirac has no assigned value at 0. You can assign the value in your preliminary code as a "remember table assignment":

Dirac(0):= 1

The old way that you mentioned still works in general, but your examples int and type are just unlucky choices. They are both special cases, but in completely diffferent ways.

Regarding type: It is a builtin command, meaning that it is not written in Maple and is "built in to" the kernel rather than stored in the Library. There is no way to list the code of builtin commands, and there never has been a way.

Regarding int: It has been recoded with a module wrapper. Your print method will not work with modules. But there is still an underlying procedure inside that module, and you can view it with showstat(int) or

interface(verboseproc= 3);
kernelopts(opaquemodules= false);
print(int:-ModuleApply);

When a command cmd has a module wrapper, the module's name is cmd and the procedure's name is cmd:-ModuleApply. When you're trying to read code, you usually want to set opaquemodules to false, as above, which gives module locals the same accessibility as exports (via the : - operator) except that the locals won't be affected by the with command.