Stream IDs are used to represent multiple data streams within a connection, and each ID must be unique to that stream. For example, if a consumer opens a login stream, a directory stream, a stream requesting item TRI.N, and a stream requesting item GOOG.O, each of those four streams must use a Stream ID different from the other three (the Login could use ID 1, Directory 2, TRI.N 3, and GOOG.O 4). The UPA Dev Guide has more information; see the "Stream Identification" section.

The rsslWatchlistConsumer leverages the Consumer Watchlist Value-Add component which provides message routing, fanout, and recovery features for the application. To do this it creates and manages its own streams, which aren’t necessarily 1-to-1 with application streams, which it why it remaps stream IDs it sends to the provider. If you connect unmodified rsslWatchlistConsumer and rsslVAProvider examples directly, you should see that the rsslWatchlistConsumer receives the requested content with the Stream ID it used even if the ID reported by rsslVAProvider is different. Examples that do not use the Watchlist component (e.g. rsslConsumer, rsslVAConsumer) write messages directly to the connection and so will not see their IDs modified.