If you want to follow the Snodgrass approach, you have my deepest sympathies. You may want to glance at my approach, if only for comparison. And I would be remiss if I did not at least mention Tom Johnston, who has a new book on the subject. It is at least an improvement on Snodgrass!
However, the issue of adding or removing columns to temporal data is fairly implementation independent. But one goal of my implementation is that current and past (and even future) data all reside in the same table or set of tables and is available with the same query. This effects the rest of my answer.
When adding new attributes to temporal data, you must decide what the value of those attributes will be during the time period prior to their existence. And that value may be quite different for valid time and transaction time.
The valid time query asks, "What was the state of the entity at the designated date and time?" How you implement the new attributes will depend on if you can answer that question using those new attributes. If you don't know, or if the past state is irrelevant, then just leave the value
null (the default for new columns). Otherwise you must update the new attributes in all the past versions (and by "update" you should know I mean "create new versions"). Not a task I would relish.
A transaction query asks, "What was the state of the entity as it was stored in the database at the designated date and time?" Obviously, the new attributes had no representation prior to their creation, so to be absolutely true to the contract of the query, those attributes should not even appear in the result set. That will be extremely difficult to implement. Good luck with that. Probably the best compromise would just be to show the values as
null which, meaning "unknown", is about as accurate a description as any.
Removing attributes means those attributes are no longer relevant. The question then becomes, "Were they ever relevant?" If the answer is no then just drop the columns. Yes, you are changing history, but you are removing irrelevant data so the meaning of the past will not be changed. If the answer is yes then the column(s) must remain. The current values may be set to
null and/or any "current" view may be rewritten to ignore those columns, but history must be maintained.
This illustrates the point that temporal modeling takes much more effort than non-temporal modeling. But, of course, sometimes the real-world object changes or we discover new attributes. Who could have foreseen that "ChargeTime" or "SelfDriving" would be needed as attributes when modeling an automobile as recently as a decade ago?
The above are considerations from strictly a designer's point of view. Regulatory requirements, if applicable, may add their own restrictions.
Good luck. Keep in touch.