Issue 1:
I looked at the issues and did not find something related, so I hope it's not a duplicate.

Description

I fitted a DecisionTreeClassifieron a single feature and had a look at the threshold attribute of the Tree object. I observed that there were a lot of thresholds equal to -2, though my feature took only positive values. Using this example from the documentation, I realized that all leaf nodes had a threshold equal to -2. Since leaf nodes don't have a threshold, I would have expected np.nan for these thresholds.

Steps/Code to Reproduce

import numpy as np
from sklearn.tree import DecisionTreeClassifier

X = np.arange(10)[:, None]
y = [0] * 5 + [1] * 5

clf = DecisionTreeClassifier(criterion='entropy')
clf.fit(X, y)
print(clf.tree_.threshold)

Expected Results

array([ 4.5, nan , nan])

Actual Results

array([ 4.5, -2. , -2. ])

Bigger example (using the example from the doc)

import numpy as np
from sklearn.tree import DecisionTreeClassifier

rng = np.random.RandomState(42)
X = np.abs(rng.randn(1000, 1)) # All the values of X are non-negative
y = rng.randint(2, size=1000)

clf = DecisionTreeClassifier(criterion='entropy')
clf.fit(X, y)
clf.tree_.threshold

n_nodes = clf.tree_.node_count
children_left = clf.tree_.children_left
children_right = clf.tree_.children_right
feature = clf.tree_.feature
threshold = clf.tree_.threshold

node_depth = np.zeros(shape=n_nodes, dtype=np.int64)
is_leaves = np.zeros(shape=n_nodes, dtype=bool)
stack = [(0, -1)] # seed is the root node id and its parent depth
while len(stack) > 0:
node_id, parent_depth = stack.pop()
node_depth[node_id] = parent_depth + 1

if (children_left[node_id] != children_right[node_id]):
stack.append((children_left[node_id], parent_depth + 1))
stack.append((children_right[node_id], parent_depth + 1))
else:
is_leaves[node_id] = True

print("Number of leaf nodes: {0}".format(is_leaves.sum()))
print("Number of thresholds equal to -2: {0}".format(
(clf.tree_.threshold == -2).sum()))
print("All leaf nodes have a threshold equal to -2: {0}".format(
np.all(is_leaves == (clf.tree_.threshold == -2)))
)

Number of leaf nodes: 505
Number of thresholds equal to -2: 505
All leaf nodes have a threshold equal to -2: True

Versions

System:
python: 3.7.1 (default, Dec 14 2018, 13:28:58) [Clang 4.0.1 (tags/RELEASE_401/final)]
executable: /Users/johann.faouzi/anaconda3/bin/python
machine: Darwin-16.7.0-x86_64-i386-64bit

BLAS:
macros: SCIPY_MKL_H=None, HAVE_CBLAS=None
lib_dirs: /Users/johann.faouzi/anaconda3/lib
cblas_libs: mkl_rt, pthread

Python deps:
pip: 18.1
setuptools: 40.6.3
sklearn: 0.20.1
numpy: 1.15.4
scipy: 1.1.0
Cython: 0.29.2
pandas: 0.23.4

Issue 2:
A while ago we talked about the possibility of a version 2 with breaking changes. Specifically, this came up in the context of SLEP006: metadata routing, but there are other things we have wanted to break which we can do all in a single release. In this issue we can talk about the possibility of such a release, and maybe a few things we'd like to include in it.

I'll try to summarize the challenges of keeping backward compatibility (BC) in the context of SLEP006:

MetaEstimator(Estimator()).fit(X, y, sample_weight) will raise according to SLEP006 since sample_weight is not requested by any object. For backward compatibility, during the transition period, it'll only warn and assume sample_weight is requested by Estimator().

What should the behavior of GridSearchCV(Estimator(), scorer=scorer).fit(X, y, sample_weight) be during the transition period? If we keep backward compatibility, it should warn (whatever the warning be), route sample_weight to Estimator, but not to the scorer. And that's only the case because we're keeping BC. From the user's perspective, it's very weird.

Pipeline ATM in certain methods like fit, fit_transform, predict, routes *_params to the fit/etc of the last estimator only. And decision_function and transform, score_samples have no routing at all. Keeping this BC, proves to be challenging, and a bit nasty. ref: #24270

In quite a few meta-estimators, we check if the sub-estimator has sample_weight in the signature of fit, and we pass the given sample weight to it if that's the case, and not if that's not the case. With routing, we would have a much better idea of when to pass sample weight and when not, but if we're keeping BC, it's really challenging to see if we should forward sample weights or not. Both AdaBoost (#24026) and Bagging (#24250) have been very challenging, to the point that we might end up having to check if a sub-estimator is a meta-estimator itself or not, and check signature of sub-estimator's fit, and check the given routing info to keep BC.

I'm pretty sure there are other issues we haven't foreseen, and they'll come up as we work on this project. We thought it'd be easy once we get to this point, but BC has proven to make it very tricky and has stalled the progress.

All of the above is adding substantial complexity which is probably error prone, and buggy. We have had to spend quite a bit of time every time we go back to review those bits to understand why we've done what we've done. Even as a temporary solution they're not very maintainable.

My proposal here is to have a version 2 which is not BC with previous releases in certain ways, and target a few breaking changes for it. We can aim to have the release in October 2023 or April/May 2024 as the version 2.

cc @scikit-learn/core-devs