@Mariusz Iwaniuk Amazing simplification; vote up! How did you guess that useint would help?

My guess is that any "function-like" expression which doesn't contain hypergeom or MeijerG is considered simpler than any that does. By "function-like", I mean to exclude expressions with unevaluated limits, integrals, sums, etc. Those are essentially "meta-functions" to my mind. Because of the way that the arguments of hypergeom and MeijerG are grouped into lists, these functions have an arbitrary number of parameters. Every reduction of the number of parameters could be considered to add a whole "order" of "simplicity". If you look at the definitions of hypergeom and MeijerG on their help pages, you may understand what I mean.

Your intuition is that any proper (or idealized) simplifier S must impose a partial order simpler on its set of possible inputs, at least implicitly, and that S(e) should be minimal wrt simpler. Clearly, this must be true wrt the size option if it's to be meaningful. I think that this partial ordering concept is also true (at least in theory) when simplify is used without an option. The question then becomes What exactly is the partial ordering used? This would be a wonderful addition to the documentation, although it may be the size of a small book.

One consequence of this is idempotency: For any e, S(S(e)) = S(e). I have occasionally (extremely rarely (like twice in 20 years)) seen cases where simplify (with no options) violates this, and these can be considerd bugs.

@nm If f is any symbol, and t is any type, then 'f(t)' is a type that matches functions named f having exactly one argument, with that argument being type t. The difference between 'f(anything)' and specfunc(f) or specfunc(anything, f) is that the latter two will match functions with any number of arguments. Note that the quotes are often needed on 'f(t)' because f is often a procedure name.

This also explains why it didn't complain about your misspelled type.

Christian's Answer seems obfuscated.

@nm You mean extra c, not extra s.

It is interesting that the first 5 of the 6 solutions from dsolve are of the form A_i*(x^(5/2))^(3/5), where the A_i are 5 specific algebraic-number constants. These 5 have no general integration constant. The 6th solution, when solved for y(x), becomes

y(x) = RootOf(_C1*_Z^2*x^(3/2)+x^(5/2)+_Z^5)^3

So, that's essentially the roots of a 5th-degree polynomial.

@syhue I don't understand "ady". Does it work, yes or no?

@Rouben Rostamian  Yes, thanks, that is an improvement.

@Oliveira The uses P= Physics form is safer, but it isn't 100% safe. If you actually execute gds, and it does use P:-diff, the global state will be altered, and it won't be reset when the procedure exits. This global state alteration is of the form shown by Rouben and in your worksheet below. But in neither case will references to diff outside the procedure invoke Physics:-diff rather than ordinary diff.

@Oliveira Yes, your worksheet immediately above does show leakage from the Physics package. This leakage is of exactly the same type as described by Rouben in his Reply to your main Question. However, it is not leakage of the Physics:-diff command specifically. The diff that was executed outside the procedure is indeed the global :-diff, not Physics:-diff.

Your worksheet immediately above is indeed an illustration of a bug, and I'm glad that you presented it. But the code in your main Question does not show any bug or undesirable behavior.

@Rouben Rostamian But the OP's first example does not show leakage of Physics:-diff!!! The Physics:-diff is indeed confined to procedure gds!

Yes, Physics does indeed leak in the way that you showed, the display form of the derivative, and other ways also. That's a separate issue, which is not shown by the OP's example.

@Christian Wolinski The presenting issue is not the desire to eliminate the error message (although that may also be desirable); it's that the error message refers to Physics. This is totally normal and expected.

@Rouben Rostamian  

This is a very serious issue, IMO, and you should make a separate Post of it. The situation is even a little worse than you state, because the global-state change happens regardless of whether the procedure is executed (via doit(), for example); merely its definition need be executed. 

This is not specific to Physics. What's happening is that 

uses <some module name>; 

causes the execution of that module's ModuleLoad procedure (if it exists). Usually, the main purpose of a ModuleLoad is to change the global state (for example, to define types specific to the module). A conscientious module author should include a ModuleUnload procedure to restore the global state. A ModuleUnload is executed when the module is garbage collected. Garbage collection can be forced by 

kernelopts(unread= <module name>);
gc();

However, a related critical-severity bug specific to Physics is that the above code will cause the kernel to freeze, requiring it to be killed externally.

I have always been skeptical of the uses statement, and now I see that that has been justified! A safer alternative is

uses P= Physics; #or any module

@Rouben Rostamian Vote up. Thank you for pointing out this technique that I was unaware of: the option for symbolic dsolve that lets one solve for scalars as well as functions:

dsolve(..., {y(x), omega})

I am very familiar with the equivalent option for numeric BVPs (whose syntax is quite different).

Maple (as of Maple 2018) has a built-in Python interpreter. Perhaps that will suit your needs, and with less hassle than coordinating separate processes. See ?Python.

@glcrawfo That's the way I guessed, so my solution worksheet is already posted below.

Please study the input forms closely. Note carefully how derivatives are entered.