This problem you mentioned is new to me - have not seen it before. Did you file a Github issue for this? Happy to chat more there (or feel free to ping me directly - ajay (at) timescale.com).
Just try to do a massive '\copy from' into a table that is already a timescaledb, using a tsv source with at least a few million records, make sure the dates are well spread out. Then use windowing functions to count the records per time unit. Compare date_trunc to time_bucket and select. Unless the issue was silently fixed, I'm sure you will be laughting too - but I recommend you wait until after xmas to have that good hearthy laugh, as it may cause you to want to fix the issue ASAP :)
Once of the field was defaulting to NOW(), maybe that's what caused the funny bug but I didn't investigate much after that. It was the straw that broke the camel back. Thousand papercuts. Not worth the time investment.
One of the many papercuts was actually more serious, to the point it was funny: I remember how in their stable versions, they had a humorous bug: if you did \copy instead of insert to a timescaledb, the timestamps looked right when you eyeballed them with a select, but acted wrong when you used them in a query.
Theefore it passed tests, but took down production whenever than happened. Ouch.
To their credit, they preserved this bug very well for several stable versions - for far longer than my patience with broken software.
That's quite bad for a database that intends to do timeseries - something so basic you won't ever see in proprietary software.
Then before there was pipelinedb which also had its fair share of bugs before going under. Some of them took a production database offline. But it was such a CPU hog that it had been anticipated.
Still after that timescaledb bug, I banned the use of third party postgres extensions.