GCC implements two transaction keywords (__transaction_atomic and __transaction_relaxed instead of just __transaction), and this is also what the next version of the specification will require. Furthermore, there is only static checking of atomic transactions, exception specifications have been replaced with (optional) noexcept specifications as in C++11, and cancel-and-throw is not implemented by GCC currently.
Exception handling does not get more complicated because of the default commit-on-throw semantics, meaning that even if you add transactions, the behavior of code that throws exceptions will not change.
A certain variable can be accessed with and without transactions, as long as the program ensures using synchronization that there will be no concurrent transactional and nontransactional accesses of which at least one is a write (i.e., data-race-free code is required, and "concurrent" is as defined by the C++11 memory model extended by transactions). For example, you can use a transaction to remove an element from a shared data structure, and after the transaction has finished, access this element like any other private data (both privatization and publication are safe, provided that there are no data races). So, this is in line with the rest of the C++11 memory model.
We have been planning to write a TM tutorial that explains the specification in a more easily accessible way, but this just hasn't happened yet.
It is true that the current implementation uses TM algorithms that synchronize using a single global lock, but this is due to just not having enough time yet to include other algorithms. However, GCC's TM runtime library (libitm) has all the code in place to easily add further algorithms and switch between them at runtime. As a side note, using a single lock is not necessarily bad but depends on the workload at runtime; if transactions are executed rather infrequently, are often read-only, or have frequent data conflicts anway, this performs better than other approaches.