@dylad, I didn't went through all the changes here yet but I had a look at the Bosch original driver. One thing I like there is that they provide a generic implementation, agnostic to the underlying hardware API: one can provide the SPI/I2C read/write functions to the driver and it does the job.
So do you think that it wouldn't be simpler to add bosch driver as a package and provide RIOT specific SPI/I2C read/write functions there ? I have no clear idea how to achieve this, but I think that would reduce the diff of this PR and avoid having to maintain a complete driver implementation.

I can work on providing an external package but we will loose the benefit of the SAUL implementation and TBH I don't like the way Bosch wrote this driver :)
I'll check which solution is the less dreadful.

After some changes, I could also contribute a BME680 device driver, which I wrote completely from scratch almost a year ago for ESP-IDF and esp-open-rtos (https://github.com/gschorcht/bme680-esp-idf). It is working with SPI and I2C as well. It supports all complex features and configurations of the sensor.

My plan was to work on it in a few days to port it to RIOT but now I have seen this PR and I wonder if it still makes sense.

After thinking about it, maybe @aabadie is right. I'll provide this driver as a pkg, this way, we will let @boschsensortec maintaining their little toy and we will avoid this 'burden'.
I'll provide it in another PR, hence I'm closing this one.