One or more of the following people are relevant to this code:

• @Cryoris
• @Qiskit/terra-core
• @ajavadia
• @mtreinish
• @nkanazawa1989

There are some issues I'm feeling difficulty in solving with ParameterExpression implemented in Rust space.

• Do we have to accept ndarray for right hand side parameter for operators?
• Do we have to test with is operator (in AssertIs) on Python? I think checking the equality with symbol name and uuid is enough.
• I implemented with a single structure ParameterExpression, so we can not identify the instance as Parameter, ParameterExpression or ParameterVectorElement. Can we change test cases by comparing with __repr__ to identify parameter types?

There are some issues I'm feeling difficulty in solving with ParameterExpression implemented in Rust space.

* Do we have to accept `ndarray` for right hand side parameter for operators?

I'm not sure I understand what your asking about here. Do you mean something like Paramter("b") + np.array([1.0, 2.0, 3.5])? I wouldn't expect that to be supported tbh. But I could also see how something in SparsePauliOp's symbolic mode needing that.

* Do we have to test with `is` operator (in  `AssertIs`) on Python? I think checking the equality with symbol name and `uuid` is enough.

I think this is probably fine, we have this limitation already for many things that get returned from circuits already. There might be a backwards compatibility concern here depending on exactly where this comes up. But if you write an upgrade release note documenting exactly what and how this is changing we can discuss the specifics during the full review. But in a lot of places tests that were doing self.assertIs were just poorly written making undocumented assumptions about how things are stored under the covers).

* I implemented with a single structure `ParameterExpression`, so we can not identify the instance as `Parameter`, `ParameterExpression` or `ParameterVectorElement`. Can we change test cases by comparing with `__repr__` to identify parameter types?

This isn't sufficient. The exact typing here is part of our API contract and doing __repr__ comparisons is not sufficient (or even a common pattern). There are a lot of places we do something like isinstance(param, Parameter) and this needs to still work the same way.

I'm going to close this as #14757 just merged. That PR took this as a starting point and continued it so this has effectively merged. Thanks for all the work on this.