iBO for .NET not 'supported' but officially integrated into product

OK this gets me everytime. As I continue to develop using iBO for .NET. I am always run into some issue. Like a good boy because the product is marked as 'ETP' in this fine community I go into the forums and document the issue.

With iMIS 15 release I am discovering the same issues I had with iBO for .NET is happening in the Casual View and public view.
The reason...
iMIS 15 release uses iBO for .NET for some of the web view components. fair enough... It is good that ASI is using their own API for their product.

The Issue...
iBO for .NET is still marked as ETP. So I now play a cat and mouse game with ASI. I discover an issue with iMIS as an SMR. I continue to determine the point of failure. I discover the failure in iBO for .NET. I update the SMR. They respond 'iBO is an ETP and we do not support it' I then fire up Casual/public view and confirm that it is happening in the Casual/public view. Casual/public view is part of the iMIS product, thus it is 'officially' granted an SMR status.

If code is marked as ETP or beta.. DO NOT INCLUDE THE CODE IN PRODUCTION. If beta code is placed in Product at least have the forth thought to review iMISCommunity the place where all iBO for .NET issues are being recorded. ASI should have the knowledge of what components of iBO for .NET is or is not in iMIS 15 production and review iMISCommunity every day. Someone at ASI who cares about iMIS should review the list of issues and go 'hmmm let me test if this effects the iMIS 15 product'

I submitted the issue regarding iBO not saving ID in the Name_Log table for any single-instance demographic changes in November. I documented here because it was an iBO issue. I later realized the issue affects Casual/public view.. So I submitted an SMR. I am still awaiting feedback as to what level the SMR is placed let alone a timetable of resolution.

We shouldn't be spending all this time fighting to get bugs marked as 'official' issues.

Either let us document iBO errors via SMR, or don't include ETP code in production. We can't have it both ways ladies and gentlemen. no wonder time between discovery and resolution is sooooo slow with iMIS 15