@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.

@mmcdara Well, maybe that's what they want, with the addition that the initial conditions have consistently been given as x(0)=10, D(x)(0)=0. But the first statement of the problem has R as the coefficient of the 2nd derivative and now it's been changed to LC. All that I need to know is which of those two is correct.

@glcrawfo Okay then, all I need is for you tell me why you switched R to LC and L to RC. 

@glcrawfo You have many, many typos. First answer my question about RC and LC. Once you do that I can finish the problem, and I'll post a worksheet done in plaintext Maple Input. 2D Input is crap, which is not your fault, because Maple stupidly made it the default input mode.

@glcrawfo Why have you changed the ODE so fhat the coefficient of the 2nd derivative is L*C when it used to be R and that of the 1st derivative is R*C when it used to be L? Which version is correct?

It will be much easier for me to explain the rest of your numerous typos to you if you switch your entry style to Maple Input. It's currently 2D Input. You could simply open the worksheet that I attached to a previous Answer. It's written in Maple Input (all the input code is reddish-brown bold monospaced characters). Let me know if you can do that. 

@glcrawfo Are you sure that there's supposed to be an x(t) on the right side on the ODE? That's not what you had at first, and it's not the standard way that ODEs are written, (although it's still mathenatically valid). So, it seems strange.

@glcrawfo Okay, that's better; I'm begining to understand. Should "(-1) and n" actually be "(-1) to the n^th power", which is denoted in Maple (-1)^n?

I told you before that your piecewise function makes no sense, and you haven't changed it! It doesn't even have balanced parentheses! I understand the rest of the problem fine. A piecewise function (for this context) has alternating inequalities and algebraic expressions. You just have a single algebraic expression inside piecewise(...); you have no inequalities.

Do not post this as a new Question! If you do it again, I'll delete it. Edit this version instead.

@Oliveira Are you saying that when you solved this in Maple, you only got the middle piece of the piecewise, as shown by the plaintext result in your Question?