If you feel that your scenario is very different than the StockListDemo one, you should rewrite your Data Adapter from scratch, rather than trying to amend our sample code.
If you still want to make improvements to the sample StockListDemo code, please provide us with more details on the requested functionalities and we will try to give you some hints.

About your points, from a broad perspective:

1) Lightstreamer Server doesn't need to be restarted as soon as new items become available. However, if the Data Adapter refuses a "subscribe" request for an item (i.e. it throws a SubscriptionException) it caches the answer on the item until it has been unsubscribed by the same client. Hence, if the item, eventually, becomes available, new clients may still find it as unavailable.
If you know that an unavailable item may become available, it may be better to accept the subscription and (temporarily) provide no data or an empty snapshot.
The problem should disappear with the next major release of the software, where the item lifecycle management will be revised.

2) You may choose to split an item into two items, in such a way that some fields pertain to the first item and the other fields pertain to the second item. Obviously, the clients, the Metadata Adapter and the Data Adapter should all be consistent with the choice. However, you cannot separate two fields into two distinct items if you need that the field values are always in sync (for instance, because you need to make real-time comparisons or compute real-time derived values from the two fields).