I don't think so. Having several sets of language-level constructs for transactions does not seem to be useful. If you want to just change to a different implementation of these transactions, you can already do so by using another library instead of libitm.
If you're thinking about interfacing with other transactional systems (so, for other resources besides the application's address space), then you should look at the transaction_wrap function attribute, with which you can declare transactional wrappers for functions (e.g., library functions). However, this isn't yet part of any specification.