Weird Optimizer Choice

I'm very puzzled by the choice of NC index being made by the optimizer
in this example. I don't actually think it should use an NC index at
all.

I have:

Table: CustomerStatus_T
Single data page
19 records
Clustered Index on CustomerStatusID:

CREATE TABLE [CustomerStatus_T] (
[CustomerStatusID] [int] NOT NULL ,
[Name] [varchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[Description] [varchar] (200) COLLATE SQL_Latin1_General_CP1_CI_AS
NULL ,
[Code] [varchar] (30) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[CodeAlt] [varchar] (30) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[Ordinal] [int] NULL ,
[Default] [int] NULL ,
[Display] [bit] NOT NULL ,
[StatusType] [varchar] (1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,
[DateCreated] [smalldatetime] NULL ,
[DateUpdated] [smalldatetime] NULL ,
[DateArchived] [smalldatetime] NULL ,
CONSTRAINT [PK_ROMS_CustomerStatus] PRIMARY KEY CLUSTERED
(
[CustomerStatusID]
) ON [PRIMARY]
) ON [PRIMARY]


If I run the following query, it does exactly what I expect and scans
the clustered index:

SELECT customerStatusID, [Name] FROM CustomerStatus_T
WHERE dateArchived IS NULL
AND Display = 1
AND StatusType = 'Q‘

and gives the following QEP and IO statistics:

|--Clustered Index Scan
(OBJECT:([Reach_Roms].[dbo].[CustomerStatus_T].[PK_ROMS_CustomerStatus]),
WHERE:(([CustomerStatus_T].[DateArchived]=NULL AND
[CustomerStatus_T].[StatusType]='Q') AND
Convert([CustomerStatus_T].[Display])=1))


Table 'CustomerStatus_T'. Scan count 1, logical reads 2, physical
reads 0,
read-ahead reads 0.


If I now put a NC index on the statustype column:
create index ix_nci_statustype on customerstatus_t(statustype)

the query plan changes to:

SELECT customerStatusID, [Name] FROM CustomerStatus_T
WHERE dateArchived IS NULL
AND Display = 1
AND StatusType = 'Q‘


|--Filter(WHERE:([CustomerStatus_T].[DateArchived]=NULL AND
Convert([CustomerStatus_T].[Display])=1))
|--Bookmark Lookup(BOOKMARK:([Bmk1000]),
OBJECT:([Reach_Roms].[dbo].[CustomerStatus_T]))
|--Index
Seek(OBJECT:([Reach_Roms].[dbo].[CustomerStatus_T].[ix_nci_statustype]),
S EEK:([CustomerStatus_T].[StatusType]='Q') ORDERED
FORWARD)


Table 'CustomerStatus_T'. Scan count 1, logical reads 7,
physical reads 0, read-ahead reads 0.

For some bizarre reason, the optimizer thinks that a NC index lookup
on a single-page table, which ultimately costs 7 IOs, is cheaper than
a table (or Clustered Index) scan of a single page. Why? The
showplan cost also shows that it expects the NC index to be cheaper
(which is presumably why it goes and uses it), but even after running
UPDATE STATISTICS on the table it still chooses the same idiotic query
plan.

Any thoughts, or has anyone seen similar behaviour before, and can
anyone please explain it to me?

p.s. I don't actually WANT to put a NC index on this table, but I
noticed the behaviour by accident which is why I'm asking the question
:-)