Explicit transaction-timeout of a previous transaction from the same thread used instead of default transaction-timeout

A web-application uses alternately

1. user-transactions with an explicit transaction-timeout

2. user-transactions without an explicit transaction-timeout

3. implicit transactions (calling a method of a CMT-EJB requiring transactions)

At least since the Wildfly-version v15.0.1 (older ones not tested) to v26.1.1 can be observed, that in some cases of type 2.) and 3.) not the default transaction-timeout from the appserver-configuration, but the explicit transaction-timeout of a previous case 1.) applies, obviously if the request is served by Wildfly on the same thread. This is only noticeable, if enough cases of type 1.) occur, the explicitly set transaction-timeout is low enough and the duration of the operations in the cases 2.) and 3.) is high enough to exceed that timeout.

I couldn't discover any misbehavior of the application so far and I'm assuming this is a bug in the application-server.
While for the case 2.) there is a practical workaround of always setting a transaction-timeout (introduce an application-local default timeout), it becomes complex for the case 3.) (no timeout can be specified for CMT-beans, the application could only surround all the EJB-calls from a non-transactional context with a user-transaction, which is for a high count of calls not really viable).