This is not a well-formulated problem, and the answer depends on what you are trying to do.

* If you are just trying to find an eigen modes of two coupled qunatum oscillators, the standard approach would be to solve the problem of two coupled classical oscillators, find their nomal modes (eigen values), and then quantize these normal modes (declare them to be independent quantum oscillators).

* If you are trying to solve a problem of two coupled quantum systems directly: good luck. You need to symmetrize the wave function (it is bosonic), formulate boundary conditions and solve a variant of boundary value problem (like Sturm–Liouville problem but worse) with partial derivatives in two coordinates.

* Another standard approach would be to use second quantization first, in this case it will be eventually reduced to a matrix diagonalization problem (Coupled Harmonic Oscillators | Applications of Quantum Mechanics (cornell.edu)).

@Carl Love All good! And thank you for helping out. I very much appreciate your feedback. That's how I learn. :-)

@Carl Love Agreed. I was wrong.

Would it help to use eval(g(x), x = 1)? In contranst to subs, eval can handle derivatives properly while subs means symbolic (literal) substitution. So when you are doing subs(x = 1, g(x)), it means diff(g(1), 1), (not diff(g(x), x) at x= 1) and that is the problem.

Maple programming guide has some more information in this section: 3 Maple Expressions - Maple Help (maplesoft.com) Substituting Subexpressions:

The eval command performs substitution on the expression considered as a DAG rather than a tree, so it can be quite efficient for large expressions with many repeated subexpressions.

An alternative to the eval command is the subs command, which performs syntactic substitution. It computes the expression as a tree and replaces subexpressions in an expression with a new value.

@Carl Love Thank you for a quick response. Good to know it works. It was probably a coincidence that it didn't work for me. Maybe some browser issues... I did from Edge both times.

It looks like providing it an explicit method option `int(integrand,t, method=Parts);` works for both examples in Maple2023.2. This is a new feature in Maple2023. The same command in Maple2022.2 gives: 

Error, (in IntegrationTools:-Indefinite) unknown indefinite integration method Parts

From the Maple2023 Release Notes:

The int command now exposes more internal routines for indefinite integration through the method option.  It is now possible to directly call the integration by parts routine Parts and a parallel version of the Risch algorithm ParallelRisch.

I tired the first version. Same result in Maple2022.2 and in Maple2023.2.

Edit: I enabled a trace. It looks like `tr_is_cos` means: ""error in TrigExpOnly: cannot determine if this expression is true or false: tr_is_cos" but I could not get any further.

handler_trig_exp_only_nov_18_2023.mw

@Carl Love Thank you for pointing out the short form of a syntax for assumptions. Didn't know about that.

@awass I agree that this looks counter-intuitive and confusing for new Maple users (like myself), so that in order to understand such subtle differences, one literally has to get throuhg the entire Maple Programming Guide.

I wonder what options do Maple developers have in this case. As a programming language, Maple appeared in 1980-x in a completely different world and with design goals in mind specific to that time, and as of 2023 we still have to live with these design decisions. As the language evolves, and new stuff is being added, it has to coexist with old constructs due to backward compatibility with existing code base... I  would guess that re-designing it from scratch with all modern innovations (so that it would look internally like e.g. Julia) is prohibitively costly for a single company like Maplesoft.