Fundamentally, the 2.x born to refresh the project which exists since Drupal 4.6 and from its first version had not many changes in features or number of services.
So after a consultation with the Drupal community about tastes, uses and wishes, Service Links got its path and became a little framework that can load dozen of services and sort them with a graphical interface and plus developers may expand the original equipment just implementing the hook_service_links() (don't need anymore overwrite the original module) which have to return an array of self-descriptive items (readable code) without care anymore about the admin section (declaring this little hook is enough to make them appear on the admin service page).
So, the 2.x was focused on the separation between the list of services and the main module with the minimum effort needed by a third part developer interested to extend the range of services, but also including features that a module like this should have: the ability to use short-url services, configure different icons, sort services on a visual UI, add blocks with indipendent styles appearing on not-node pages too, smoothing and optimizing for a best integration with important external modules.
The model of link considered was the static one, easy to integrate, using a standard XHTML anchor tag without any claim, afterwards when the widget mania exploded among the social networks, Service Links aimed to integrate the Twitter and Facebook widgets improving and modifying the core. However there are other modules which handle widgets older than Service Links, and i can understand how frustrating is, duplicate common features for each one: who want add a new widget creating his custom module, have to instantiate an admin page where configure all the settings needed and one or more hook to create blocks or page alteration, the result? Too much time to correct issues that someone fixed on another module, too much dispersion for one common target.
In this sense, Service Links 2.x give already a good point to start, the only needed things are the list of service settings and some callback module that introduce exotic tags (look at services/widget_services.module), and this part could be improved.
The work made on the 2.x branch is a lot, but honestly, Service Links 2.x is already obsolete compared to the Drupal 7 code.
Drupal 7 is build around the CCK module which is a great solution looking at what a CCK field does:
... all this almost for free.
The third version should be developed around CCK, embrace its philosophy but taking advantage of the previous experience adding features like:
First of all it's important gather knowledge about all the widgets already codified by external modules. Would be great if the owners of these modules will partecipate to the list of requests, asking for a particular tag or explaining why their widgets couldn't work on Service Links. But is also important discover new widgets not yet included on the long lisf of available modules, to be sure that all the resource needed can be coded like array items, where the level of difficult is too high either a work doesn't worth the efforce, we could always use the callback function.
There are also other widgets that are not strictly tied to the content sharing and could be added into a different module.
I am thinking to widgets like Skype and similar which announce the user's availability on one of those messenger systems. So the widjets user oriented will be another great add with a not big efforce since CCK fields work also on user profile, but need other kinds of data to be displayed!
I think i gave a first look on what i would achieve for the next Service Links branch, maybe i missed something so feel free to add a comment explaining wishes, suggestions and everything except spam, lol.