Using "android.R.id.content" causes "sticky" initial fragment

[Adlatus]

I noticed a difference in the behaviour of fragment handling (using FragmentManager/-Transactions) between ABS and the regular Android framework plus android-support-v4.jar library:

I have a (Sherlock)FragmentActivity which hosts two fragments, one of which is full-screen visible at a time. Background style is transparent. When tapping on the activity window, the screen switches between the two fragments.

Before I used ABS, this has worked just fine. Now, since I introduced ABS (because I want to use the ActionBar), the first fragment persists on the screen, and on all subsequent clicks, I see the alternating two fragments plus the unwanted, persisting first fragment (at least when I use the transparent theme/style). This is when running on an Android 2.2 phone/emulator, it works fine with Android >= 4.0. Here is my sample code (differences between implementation without and with ABS in brackets [ ]):

public class MainActivity extends [Sherlock]FragmentActivity implements
        OnClickListener {

    private DemoFragment frag1 = new DemoFragment();
    private DemoFragment frag2 = new DemoFragment();
    private boolean frag1active = true;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        findViewById(android.R.id.content).setOnClickListener(this);

        frag1.text = "Frag1";
        frag2.text = "Frag2";

        // Activate Fragment1
        FragmentManager fragMgr = this.getSupportFragmentManager();
        FragmentTransaction fragTrans = fragMgr.beginTransaction();
        fragTrans.add(android.R.id.content, frag1);
        fragTrans.commitAllowingStateLoss();
    }

    @Override
    public void onClick(View v) {
        // Switch fragments
        FragmentManager fragMgr = this.getSupportFragmentManager();
        FragmentTransaction fragTrans = fragMgr.beginTransaction();
        fragTrans.replace(android.R.id.content, frag1active ? frag2 : frag1);
        frag1active = !frag1active;
        fragTrans.commitAllowingStateLoss();
    }
}

public class DemoFragment extends [Sherlock]Fragment {

    public String text = "not yet set";

    @Override
    public View onCreateView(LayoutInflater inflater, ViewGroup container,
            Bundle savedInstanceState) {

        Random random = new Random();
        TextView textView = new TextView(getActivity());
        textView.setText(text);
        textView.setTextSize(30);
        textView.setPadding(random.nextInt(100), random.nextInt(100), 50, 50);
        return (textView);
    }
}

I did neither define a main layout for the activity nor did I create a root view(group) programmatically in order to keep my source code compact. Instead, I do all the FragmentTransactions directly on the system-defined root view ID "android.R.id.content". This is officially encouraged by http://developer.android.com/guide/topics/ui/actionbar.html and therefore should work. Quotation:

Alternatively, if the tab content will fill the activity layout (excluding the action bar), then your activity doesn't need a layout at all (you don't even need to call setContentView()). Instead, you can place each fragment in the default root ViewGroup, which you can refer to with the android.R.id.content ID (you can see this ID used in the sample code below, during fragment transactions).

If I use a main layout or define a root View(Group), it works fine, so this is a workaround for the moment. But I still would prefer to be able to use my original slender code.