When you have a common subset of plugins that your features require, you could make another "Requirements" feature which includes the required plugins and then require that feature in your existing features. This makes it easier for you to change your set of required plugins over time.
One downside of this approach is that Feature B may not need all of the plugins from the common feature which means if you ship Feature B without Feature A it could ship more plugins than you intend.
Another item you should consider is will you be updating the features independent of each other? If you require all versions of your features to be the same, then having the new Requirements feature makes sense. But if Feature A can upgrade to version 2.0 while Feature B remains at 1.0 you will encounter provisioning conflicts if you have singleton plugins.
One more thought is that since you're creating an RCP, you may just want to run the p2 publisher over your product file to produce a lineup IU. This produces much more deterministic provisioning of your RCP application. If you're creating a simple RCP which doesn't have the standard Eclipse About dialog, then you wouldn't even need to expose features.
As a final note, you could just buy update functionality. Having written this technology for the past 5 years I can tell you there are many pitfalls. My company's product, Secure Delivery Center, makes it easy to ship your software and includes simple update support.