The old syntax for target_feature allowed enabling or disabling arbitrary features, which was convenient on ARM platforms where deciding per-function whether to use the ARM or Thumb ISA by enabling or disabling the thumb-mode feature was possible and even desirable. (For example: I'm writing Rust code which ends up running on a Game Boy Advance. Most code is compiled as Thumb for speed since the Game Pak only has a sixteen-bit bus, but if I provide an interrupt dispatcher it has to be compiled as ARM code because of how Nintendo wrote the firmware.)
The new target_feature doesn't define syntax for disabling features, only enabling them; this makes it better-suited for the things it was being used for and makes thumb-mode stand out: if a target is -avx, it doesn't have something else instead of AVX instructions, but a -thumb-mode target has a whole different instruction set to a +thumb-mode target.
As such, rather than extending target_feature in ways which risk trying to make it into both a floor wax and a dessert topping it seems more appropriate to suggest new function attributes #[arm] and #[thumb]. These would disable and enable thumb-mode for the annotated function in the same way #[target_feature = "±thumb-mode"] used to; annotating the same function with both results in a compile-time error. (I can't imagine anyone doing this deliberately, and it's good for the compiler to catch typos.) LLVM already knows how to provide the necessary interworking shims, so as far as I can tell everything should just work.
I'm unsure how inline assembly should be handled; some instructions which are legal in ARM mode are illegal in Thumb mode and vice versa, and an obvious extension of the two function attributes is to use them in cfg(...) in order to generate different code in ARM and Thumb mode. An example: the Game Boy Advance provides several library functions using the swi instruction, but in ARM mode the argument needs to be left-shifted sixteen bits, creating an invalid instruction if the file is processed in Thumb mode. Currently it's not really a problem since you can't decide one function should be compiled to the ARM ISA in an otherwise Thumb function.