It should be easy to make Stars/Ratings more flexible and SAFER (a problem documented several versions ago), with just two changes:
Larger range and 1/2 stars: Change Rating field to accept a range of 10, could be 0 to 10, or 0 to 1.0, or whatever. Map these values to stars, including half-stars. Or pick another range, but at least double the current range so numbers are available to show half-stars. Value 0 should be available to indicate "not rated"/no stars. (Personally I'd also use negative value to indicate status such as "duplicate with lesser quality", "alternate" and similar, but now I do this in a custom field and could continue that). And be sure Rating field can be displayed as its number where desired, not always forcing Stars because they take up much more space. (What some database systems do is provide Stars as a field/column display option for any numeric field that has an explicit range.)
Prevent inadvertent Rating change: Provide an option to disable (or require confirmation of) clicking displayed stars to change Rating field value, and enforce this wherever Stars are displayed. Because the current implementation -- one-click-changes-Rating -- is a huge risk to library integrity, Rating is the only field value that gets changed by one simple click, no typing/selecting/confirming. A user can click almost anywhere in MC and not harm anything, without explicit additional steps. But click the Stars display and BAM, the track now has a new Rating. It's not OOPS because the user doesn't even realize what happened, there was no expectation that a single click would alter data. In many situations this unnoticed, unintended change in Rating can cause that track to disappear from smartlists, or appear where it shouldn't. This might be noticed...never. Who rechecks all their track Ratings periodically? I suggest disabling the Star-click-changes-Rating behavior, instead require that the underlying numeric value be typed or selected, so editing Rating is like any other field.
This suggestion is aligned with earlier suggestions about UI inconsistent terminology. Having one field behave different from all the others is also a UI inconsistency that contributes to "MC is too hard".