Develop Reference

What is the purpose of setSupportActionBar? What does it do?

If there is a toolbar, it is usually passed into setSupportActionBar(). Why?

As per docs
A Toolbar is a generalization of action bars for use within application layouts. While an action bar is traditionally part of an Activity's opaque window decor controlled by the framework, a Toolbar may be placed at any arbitrary level of nesting within a view hierarchy. An application may choose to designate a Toolbar as the action bar for an Activity using the setActionBar() method.
But in simple ways, this is a way of telling the Activity that you are interested in using the features related to Toolbar. It will delegate the functionalities related to your defined toolbar. It helps activity to understand the many of the requirements some of them mentioned below.
1) Setting menu options
2) Setting Navigation drawer
3) Setting common Toolbar
4) Setting back button on the top left
5) Using an icon for brand identification
6) Setting a common title or subtitle
7) And many more
If you don't mention for these functionalities by telling the activity using setSupportActionBar then you have to create all this by your self and support them back to the older version. With Toolbar it comes free and you have to just tell a activity to use it will take of supporting different functionalities itself.

if you want to apply your custom toolbar instead of default toolbar then to set toolbar into that specific screen/activity you must be use setSupportActionBar() along with your toolbar. ;)

Toolbar as self-managed ActionBar vs Toolbar as framework managed ActionBar

Alright, I am trying to understand what I would lose if I use Toolbar as a self-managed ActionBar and not use setSupportActionBar.
AFAIK, all that ActionBar does is, provide placeholders for logo, navigation and menu items and also let Fragments add/customize the menu items.
The same functionality could be achieved using Toolbar.setLogo(), Toolbar.setNavigationIcon(), Toolbar.setNavigationOnClickListener() and Toolbar.inflateMenu() apis. Of course, directing the menu handling logic to Fragments might be lost but I think that is not that big of deal if the Activity knows which Fragment is on top and changes the menu items accordingly.
I am trying to make sure :
If I can achieve every ActionBar capability just by using Toolbar and MenuItems (and not using setSupportActionBar()).
Is it ok to not have an exhaustive knowledge of ActionBar apis. Some of the ActionBar apis are very confusing. Using setHomeAsUp api to show hamburger icon, back icon etc., doesn't feel right. If someone starts learning android today, do they even need to understand the framework's ActionBar apis?
Update : In the article Android Design Support Library under section CoordinatorLayout and the app bar, I learnt that the new paradigm app bar is a replacement for the action bar paradigm. I think action bar will soon be deprecated and we should get used to the new app bar paradigm which covers the new material design user experiences.

Yes you can use achieve similar capabilities of ActionBar in Toolbar.
Mainly the difference lies is Toolbar becomes part of View so we can much more fun playing with them to get Scrolling Techniques
You can use Toolbar separately as View & perform ActionBar alike functionalities. For example, in one of my app I use 2 Toolbar one which is set to setSupportActionBar() while other is just used for some other functionalities.
Conclusion: Well it depends upon your requirements if you want to use Toolbar as self or framework. None the less you can use it as both.
I hope this answers your question well.

To me you are right.
From AppCompatDelegate source code, method setSupportActionBar(),
When set to a non-null value the getSupportActionBar() method will return
an ActionBar object that can be used to control the given toolbar as if it were
a traditional window decor action bar. The toolbar's menu will be populated with the
Activity's options menu and the navigation button will be wired through the standard
android.R.id.home menu select action.
So these are most, if not all, the benefits you will have. As you said, it is easy to implement navigation and menu inflating through Toolbar APIs. However, I don't see what you would gain by not calling setSupportActionBar().

YES YES YES
using setSupportToolBar() is the same old Actionbar the only reason ToolBar is ToolBar is for versatility,same as Fragments is to Views, all lies on how you implement stuff, and also the old Actionbar is kinda boring and much restricted as to Toolbar

What is the difference between Action Bar and newly introduced Toolbar?

After Google introduced Material Design, I have heard about a new widget class called Toolbar.
What is the Toolbar, and what is the exact difference between ActionBar and ToolBar?

I found a good explanation from Android Developers Blog post.
In this release, Android introduces a new Toolbar widget. This is a generalization of the Action Bar pattern that gives you much more control and flexibility. Toolbar is a view in your hierarchy just like any other, making it easier to interleave with the rest of your views, animate it, and react to scroll events. You can also set it as your Activity’s action bar, meaning that your standard options menu actions will be display within it.
Yes, we, Android developers, needed more control over ActionBar, right? And Toolbar is just for it.
In other words, the ActionBar now became a special kind of Toolbar. This is an excerpt from Google's official Material Design spec document.
The app bar, formerly known as the action bar in Android, is a special kind of toolbar that’s used for branding, navigation, search, and actions.
More details like how to use Toolbar as an ActionBar are included in above blog post.

How can I use a contextual action bar with the Android support library?

I have a ListView in my ActionBarActivity that has items that can be long-pressed for additional actions.
I currently am using registerForContextMenu and showing an ugly popup dialog, so I want to change it to use a contexual action bar.
How can I do this? CHOICE_MODE_MULTIPLE_MODAL as well as a few other things seem to be API 11+.

What you want to use is ActionMode, http://developer.android.com/reference/android/support/v7/view/ActionMode.html, to implement the contextual action bar. The ActionMode is available in the ActionBarCompat library. Specifically you use ActionBarActivity#startSupportActionMode.
You can get a quick introduction in this document, http://android-developers.blogspot.com/2013/08/actionbarcompat-and-io-2013-app-source.html. See the section entitled "7. Add ActionMode callbacks".
A more complete tutorial is available here, http://developer.android.com/guide/topics/ui/menus.html#CAB.

The Android API Guide for menus (same page that Matt cited) states that:
Note: The contextual action mode is available on Android 3.0 (API level 11) and higher and is the preferred technique for displaying contextual actions when available. If your app supports versions lower than 3.0 then you should fall back to a floating context menu on those devices.
If this is still true, then it means that Android does not support contextual action bars below API level 8. Can anyone please confirm if they have used it for Froyo or below?

Tabbed ViewPager pre-honeycomb

I've been trying to setup a ViewPager with tabs in the ActionBar, but I also wanted to support older API levels (pre-ActionBar levels).
Since nearly everything that I'm trying to do in order to setup the tabbed ViewPager requires API level 11 and I can only seem to get the support libraries to go so far, I'm unsure as to what I should do.
I know I could use a TabWidget with a HorizontalScrollView to get the job done, however I don't think it will be efficient enough, nor provide the same user experience/usability/interaction, right?
or
Should I use the Sherlock Action Bar?

Sherlock Action Bar is recommended for using ActionBar in API < 4.0 not only for ViewPager movements it provides navigation like "Up" button and actionItems behaviour also if you need to in future migrate the app to support apis >= 4.0 the changes are very very little.